Problemas en la granja Costos elevados Tiempo Disponer de un experto elaborador de raciones Compra de raciones Elaboracin de raciones acordes a los

requerimientos nutricionales Conocimiento que implica la elaboracin de raciones Destreza y paciencia en la elaboracin raciones Que las raciones no son elaboradas segn requerimientos nutricionales completos Requerimientos del problema Sistema que capacite constantemente al usuario Poca experiencia en desarrollo de sistema experto Resolucin del problema con objetos y reglas Sistema automatizara el proceso de elaboracin de raciones de la granja y que cumplan con los requerimientos nutricionales El objetivo principal del proyecto es remplazar al experto elaborador de raciones para de esta forma reducir los costos y contar con una herramienta til que permita generar raciones que cumplan los requerimientos nutricionales y adems que capacite a los usuarios constantemente Ciclo de vida metodologa durkin es incremental evolutivo Evaluacin Adquisicin conocimiento Diseo Prueba Documentacin Mantenimiento Ciclo de vida ingeniera de software Requerimientos Anlisis Diseo Implementacin Pruebas Mantenimiento Modelos de proceso de ingeniera de software Modelo Lineal secuencial Aunque el modelo lineal es a menudo denominado modelo tradicional, resulto un enfoque razonable cuando los requisitos se han entendido correctamente. Modelo de Prototipos Cuando el cliente tiene uno necesidad legtima, pero est desorientado sobre los detalles, el primer paso es desarrollar un prototipo.

Modelo DRA Desarrollo rpido de aplicaciones El modelo DRA es una adaptacin a alta velocidad del modelo lineal secuencial en el que se logra el desarrollo rpido utilizando una construccin basada en componentes. Si se comprenden bien los requisitos y se limita el mbito del proyecto Modelo evolutivo incremental El modelo incrernental combina elementos del modelo lineal secuencial (aplicados repetidamente) con la filosofa interactiva de construccin de prototipos Cuando tenga una fecha de entrega imposible de cambiar, el modela incremental es un buen parodigma a considerar. Modelo evolutivo en espiral Es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construccin de prototipos con los aspectos controlados y sistemticos del modelo lineal secuencial. Proporciona el potencial para el desarrollo rpido de versiones incrementales del software Las actividades del marco de trabajo se aplican a cualquier proyecto de software que realice, sin tener en cuenta el tamao ni la complejidad. Los modelos evolutivos como el espiral son apropiados para desarrollar sistemas orientados a objetos Modelo de proceso basado en componentes para la ingeniera del software. El paradigma orientado a objetos enfatiza la creacin de clases que encapsulan tanto los datos como los algoritmos que se utilizan para manejar los datos. Si se disean y se implementan adecuadamente, las clases orientadas a objetos son reutilizables por las diferentes aplicaciones y arquitecturas de sistemas basados en computadora El diseo de la interfaz se centra en tres reas de inters: (1) el diseo de la interfaz entre los componentes del software; (2) el diseo de las interfaces entre el software y los otros productores y consumidores de informacin no humanos (esto es, otras entidades externas) y (3) el diseo de la interfaz entre el hombre (esto es, el usuario) y la computadora. Theo Mantel [MAN97] en su libro crea tres reglas de oro para el diseo de la interfaz: 1. Dar el control al usuario 2. Reducir la carga de memoria del usuario 3. Construir una interfaz consecuente Estas reglas de oro forman en realidad la base para los principios del diseo de la interfaz de usuario que servirn de gua para esta actividad de diseo de software tan importante.

CONCEPTOS Y PRINCIPIOS ORIENTADOS A OBJETOS Algunas personas argumentaran que los profesionales del software sencillamente aoraban un nuevo enfoque, pero esta visin es muy simplista. Las tecnologas de objeto llevan un nmero de beneficios inherentes que proporcionan ventajas a los niveles de direccin y tcnico.

La mejor seleccin reconocera que los sistemas OO tienden a evolucionar con el tiempo. Por esto, un modelo evolutivo de proceso acoplado con un enfoque que fomenta el ensamblaje (reutilizacin) de componentes es el mejor paradigma para ingeniera del Software OO. Las tecnologas de objetos llevan a reutilizar, y la reutilizacin (de componente de software) lleva a un desarrollo de software ms rpido y a programas de mejor calidad. El software orientado a objetos es ms fcil de mantener debido a que su estructura es inherentemente poco acoplada. Esto lleva a menores efectos colaterales cuando se deben hacer cambios y provoca menos frustracin en el ingeniero del software y en el cliente. Adems, los sistemas orientados a objetos son ms fciles de adaptar y ms fcilmente escalables (por ejemplo: pueden crearse grandes sistemas ensamblando subsistemas reutilizables). En este captulo presentamos los principios y conceptos bsicos que forman el fundamento para la comprensin de tecnologas de objetos. La nica forma de alcanzar los atributos (y operar sobre ellos) es ir a travs de alguno de los mtodos que forman la muralla. Por lo tanto, la clase encapsula datos (dentro de la muralla) y el proceso que manipula los datos (los mtodos que componen la muralla). Esto posibilita la ocultacin de informacin y reduce el impacto de efectos colaterales asociados a cambios. Como estos mtodos tienden a manipular un nmero limitado de atributos, esto es una alta cohesin, y como la comunicacin ocurre slo a travs de los mtodos que encierra la muralla, la clase tiende a un desacoplamiento con otros elementos del sistema. Todas estas caractersticas del diseo (Captulo 13) conducen a software de alta calidad. Por definicin, todos los objetos que existen dentro de una clase heredan sus atributos y las operaciones disponibles para la manipulacin de los atributos. Una superclase es una coleccin de clases y una subclase es una instancia de una clase. Estas definiciones implican la existencia de una jerarqua de clases en la cual los atributos y operaciones de la superclase son heredados por subclases que pueden aadir, cada una de ellas, atributos privados y mtodos. Una jerarqua de clases para la clase Mobiliario se ilustra en la Figura 20.5. Una de los primeros cosas o tener en cuento o la hora de construir un sistema O0 es cmo dosificar los objetos o monipular en dicho sistema Los ingenieros del software y sus directores deben considerar tales elementos el anlisis de requisitos orientado a objetos (AROO), el diseo orientado a objetos (DOO), el anlisis del dominio orientado a objetos (ADOO), sistemas de gestin de bases de dalos orientadas a objetos (SGBDOO) y la ingeniera del software orientada a objetos asistida por computadora (ISOOAC). Beneficios de de esta arquitectura OO

Los detalles de implementacin interna de datos y procedimientos estn ocultos al mundo exterior (ocultacin de la informacin). Esto reduce la propagacin de efectos colaterales cuando ocurren cambios. Las estructuras de datos y las operaciones que las manipulan estn mezcladas en una entidad sencilla: la clase. Esto facilita la reutilizacin de componentes. Las interfaces entre objetos encapsulados estn simplificadas. Un objeto que enva un mensaje no tiene que preocuparse de los detalles de las estructuras de datos internas en el objeto receptor, lo que simplifica la interaccin y hace que el acoplamiento del sistema tienda a reducirse. Las tecnologas de objetos reflejan una visin natural del mundo. Los objetos se clasifican en clases y las clases se organizan en jerarquas. Cada clase contiene un conjunto de atributos que la describen y un conjunto de operaciones que define su comportamiento. Los objetos modelan casi todos los aspectos identificables del dominio del problema: entidades externas, cosas, ocurrencias, roles, unidades organizacionales, lugares y estructuras pueden ser representados como objetos. Es importante destacar que los objetos (y las clases de las que se derivan) encapsulan datos y procesos. Las operaciones de procesamiento son parte del objeto y se inician al pasarle un mensaje al objeto. Una definicin de clase, una vez definida, constituye la base para la reutilizacin en los niveles de modelado, diseo e implementacin. Los objetos nuevos pueden ser instanciados a partir de una clase. Tres conceptos importantes diferencian el enfoque O0 de la ingeniera del software convencional. El encapsulamiento empaqueta datos y las operaciones que manejan esos datos. La herencia permite que los atributos y operaciones de una clase puedan ser heredados por todas las clases y objetos que se instancian de ella. El polimorfismo permite que una cantidad de operaciones diferentes posean el mismo nombre, reduciendo la cantidad de lneas de cdigo necesarias para implementar un sistema y facilita los cambios en caso de que se produzcan. Los productos y sistemas orientados a objetos se producen usando un modelo evolutivo, a veces llamado recursivo/paralelo. El software orientado a objetos evoluciona iterativamente y debe dirigirse teniendo en cuenta que el producto final se desarrollar a partir de una serie de incrementos.

Metodologa

Caracterstica

Etapas Identificacin  Se identifican los participantes y roles, los recursos, fuentes de conocimiento  Se establecen las facilidades computacionales y presupuestos.  Se identifican los objetivos o metas Conceptualizacin Se analizarn los conceptos vertidos por el Experto de Campo Formalizacin  Se identifican los conceptos relevantes e importantes.  El resultado de formalizar el diagrama de informacin conceptual y los elementos sub problemas es una especificacin parcial para construir un prototipo de la base de conocimiento. Implementacin  Se formaliza el conocimiento obtenido del Experto y se elige la organizacin, el lenguaje y el ambiente de programacin. Testeo Se observa el comportamiento del prototipo, el funcionamiento de la base de conocimiento y la estructura de las inferencias, Revisin del prototipo.  Se reformulan los conceptos.  Se redisea y refina el prototipo

Adecua al problema

La caracterstica ms importante de esta metodologa es la constante relacin ente el Metodologa Ingeniero de de Conocimiento y el Buchanan Experto de Campo

Constante relacin de experto y el ingeniero conocimiento

distintas fuentes: libros, expertos

La caracterstica ms importante es la obtencin de documentacin que puede reemplazar parcialmente al experto, y servir a los diseadores y usuarios como medio de documentacin y Metodologa referencia de Grover El mtodo de Grover propone una serie de etapas en el desarrollo del proceso de adquisicin del conocimiento, cada una de las cuales va acompaada de una documentacin detallada La caracterstica ms importante de esta metodologa es el desarrollo de un SE temprano, que incrementalmente converge al Metodologa sistema experto de Brule final Muchos de los trabajos en SE no son dirigidos correctamente En la mayora de los casos el problema se

Definicin del dominio  Descripcin del problema  Referencias bibliogrficas  Glosario  Criterios de performance  Escenarios de ejemplos  Identificacin de expertos Formulacin del conocimiento fundamental  Chequeo de sintaxis  Chequeo de comportamiento Consolidacin del conocimiento Basal  Escenarios nuevos  Revisin y mejoramiento

Buena documentacin en cada fases

Pre-planeamiento: Donde se define el problema, se investiga la Desarrollo factibilidad del proyecto, el costo temparano de conduccin, probabilidad de xito. Diseo y especificacin: Se crea el equipo de trabajo, estructuran las perspectivas, se planifica la primera sesin y se define el modelo perspectiva inicial mediante la creacin de un prototipo demostrativo Desarrollo temprano: El equipo realiza su primer esfuerzo de desarrollo. El final de esta ser un diseo relativamente estable Implementacin: Donde si el diseo es satisfactorio, comienza

encuentra en la construccin del software y no en la adquisicin del conocimiento

Metodologa de Blanque y Garca Martnez

La caracterstica ms importante es la etapa de planteo de causalidades, ya que los grafos de causalidades son una excelente herramienta para la representacin del conocimiento previo a la formalizacin de reglas y la verificacin, ya que compara el procedimiento que realiza el experto de campo con el que realizar el sistema; pudiendo establecer la performance del sistema

la implementacin. Es un proceso interactivo, definicin del sistema, construccin e implementacin Evaluacin: Se verifica y valida el sistema experto y se establece la performance del sistema. Supervisin: Consiste en un testeo en lnea, en un ambiente limitado y controlado. Mantenimiento: En todo sistema se requiere de un mantenimiento para poder existir y/o progresar, como as tambin la actualizacin del sistema. Adquisicin del conocimiento:  Se realiza el relevamiento del conocimiento al experto que se debe explayar lo ms posible.  De esta manera tratar de extraerle no slo el conocimiento especfico del dominio de la aplicacin sino tambin los conocimientos conexos. Enunciacin de conceptos:  Se analiza el conocimiento y se toma nota de los conceptos ms frecuentemente utilizados por el experto, esto se logra mediante la observacin del experto sobre determinadas ideas.  Resulta conveniente mostrarle una lista de tales conceptos al experto, y que l realice una clasificacin del tipo: conceptos primarios y secundarios Parametrizacin de conceptos:  Tomar los valores que se encuentran asociados a los conceptos. Por ejemplo:

Presencia / Ausencia. Alto / Medio / Bajo. Funciona / No funciona Planteo de causalidades:  Se establecen las relaciones de causalidad entre los distintos conceptos por medio de grafos causales y luego de esto se redactan las reglas asociadas. Verificacin:  Consiste en la verificacin de la aceptabilidad de las reglas con el experto de campo.  Se puede realizar usando casos de testeo que sean considerados tpicos, se comparan los resultados con los datos para los mismos casos por los expertos humanos, y en base a la comparacin se decidir si se modifican, eliminan o aceptan las reglas involucradas FASE 1: EVALUACIN. La caracterstica  Estudio de viabilidad. ms importante de  Anlisis de Costo/Beneficio.. esta metodologa FASE 2: ADQUISICIN DEL es que en el CONOCIMIENTO proceso de  Recoleccin del construccin se conocimiento. realizan pruebas  Interpretacin. que permiten  Anlisis. Metodologa generar nuevos  Diseo de mtodos para requerimientos y Jhon recolectar conocimiento nueva informacin Durkin adicional. que puede ser FASE 3: DISEO considerad  Seleccionar Tcnica de nuevamente para Representacin del su refinamiento Conocimiento. despus del  Seleccionar Tcnica de mantenimiento se Control. puede realizar la  Seleccionar Software de reformulacin Desarrollo de SE.

Se adapta al ciclo de vida propuesto por la ingeniera de software

 Desarrollo de Prototipo.  Desarrollo de Interface.  Desarrollo del Producto. FASE 4: PRUEBAS  Validacin del Sistema.  Evaluacin de la Prueba/Evaluacin. FASE 5: DOCUMENTACIN  Relacin de temas que deben ser documentados.  Organizacin de la documentacin.  Documentacin Impresa.  Documentacin en hipertexto.  Reporte Final FASE 6: MANTENIMIENTO  Modificaciones probables del sistema.  Responsables de mantenimiento.  Interfaces de documentacin del mantenimiento La caracterstica Fase I ms importante es Identificacin de la tarea: realizar plan de requisitos y adquisicin la construccin del conocimiento evaluacin y relativamente seleccin de la tarea y la rpida de un definicin de las caractersticas prototipo de de la tarea demostracin Fase II Desarrollo de los prototipos Y realizar varios prototipos gradual concepcin de la solucin Metodologa hasta conseguir las descomposicin sub problemas y determinar analogas, adquisicin especificaciones Ideal y conceptualizacin del sistema, exactas formalizacin del conocimiento y definicin de la arquitectura, Bsicamente tres Implementacin validacin y prototipos de evaluacin del prototipo investigacin, campo y operacin definicin de nuevos requisitos. que son sucesivos Fase III refinamientos cada Ejecucin de la construccin del uno del anterior, sistema integrado requisitos y para realizar estos diseo de la integracin,

prototipos hay que seguir ciertas etapas

implementacin y evaluacin del sistema integrado, aceptacin del sistema por el cliente Fase IV Se definen el mantenimiento tanto de la base de conocimiento como el del sistema integrado adems de la adquisicin de nuevo conocimiento y actualizacin del sistema. Fase V Lograr una adecuada transferencia tecnolgica Elaborar un diseo adecuado de explicacin y manejo propio del sistema en sesiones entre diseadores y usuarios