0. presentación

Informática IndustrialIngeniería de

Sistemas y Automática

Mohamed Abderrahim, Universidad Carlos III de Madrid

INFORMÁTICA INDUSTRIAL I

Ingeniería Electrónica Industrial y Automática3er curso

Profesor: Mohamed Abderrahim / Departamento de Ingeniería de Sistemas y Automática

0. PRESENTACION




Presentación de la asignatura

CREDITOS: 6 HORAS/SEMANA: 4h

– 15 clases (Teoría y revisión C)– 10 clases Prácticas

Profesores– Coordinador: Mohamed Abderrahim (1.3B02)– Teoría: M. Abderrahim y Fares Abu-Dakka– Prácticas: Carlos Alonso, Avinash, Ioannis Douratsos– Coordinador de Prácticas: Javier Gonzalez-Quijano

(1.3B13)




Calendario

Lunes 9:00-11:00 Teoría Aula 2.3.D04 G21Lunes 15.00-17.00 Teoría Aula 2.3D01 G24

SeptSemana 1 9-sep 10-sep 11-sep 12-sep 13-sep

T-1 T-2 PrSemana 2 16-sep 17-sep 18-sep 19-sep 20-sep

T-3 T-4 PrSemana 3 23-sep 24-sep 25-sep 26-sep 27-sep

T-5 T-6 Pr

OctubreSemana 4 30-sep 1-oct 2-oct 3-oct 4-oct

T-7 T-8 PrSemana 5 7-oct 8-oct 9-oct 10-oct 11-oct

T-9 FLSemana 6 14-oct 15-oct 16-oct 17-oct 18-oct

T-10 P-1Semana 7 21-oct 22-oct 23-oct 24-oct 25-oct

T-11 P-2 Parcial 1Semana 8 28-oct 29-oct 30-oct 31-oct 1-nov

T-12 FN

NoviembreSemana 9 4-nov 5-nov 6-nov 7-nov 8-nov

T-13 P-3Semana 10 11-nov 41590 41591 41592 41593

T-14 P-4Semana 11 18-nov 19-nov 20-nov 21-nov 22-nov

T-15 P-5Semana 12 25-nov 26-nov 27-nov 28-nov 29-nov

P-6 P-7

DiciembreSemana 13 2-dic 3-dic 4-dic 5-dic 6-dic

P-8 FNSemana 14 9-dic 10-dic 11-dic 12-dic 13-dic Fin Clase

P-9 P-10Semana 15 16-dic 17-dic 18-dic 19-dic 20-dic

Defensa de Semana 16 23-dic 24-dic 25-dic 26-dic 27-dic Trabajos

Semana 17 30-dic 31-dic 1-ene 2-ene 3-ene

EneroSemana 17 1-ene 2-ene 3-ene

Semana 18 6-ene 7-ene 8-ene 9-ene 10-ene

13-ene 14-ene 15-ene 16-ene 17-ene



Recuperaciones

Examenes

Examenes

Examenes

2º Cuatrimestre -clases-




Normativa

Clases teóricas (asistencia no obligatoria) Prácticas y Repaso Programación básica (asistencia

obligatoria)

– Evaluación continua– Realizar Trabajo

Evaluación– 0.4 examen final + 0,6 evaluación continua

0.15 Parcial 1 0.15 Parcial 2 0.30 Trabajo Examen final (Nota mínima 3,5)




Temario (1)

Introducción al desarrollo de sistemasinformáticos

Ingeniería de requisitos El lenguaje unificado de modelado UML y

Análisis Orientado a Objetos– Modelado estructural– Modelo dinámico/comportamiento

Diseño Orientado a Objetos Bases de datos relacionales y SQL Introducción a los sistemas de tiempo real




Temario (2)

Repaso de C Introducción a la programación orientada a

objetos en C++ Sintaxis del lenguaje C++ Conceptos básicos de clases, objetos y métodos Jerarquía de clases y herencia Polimorfismo Concepto de plantillas Manejo de Entrada y Salida Manejo de excepciones




Bibliografía

Francisco Javier Ceballos. "Programación orientada aobjetos con C++". Cuarta Edición. Ra-ma. 2007.

Francisco Javier Ceballos. "Enciclopedia del lenguajeC++". Segunda Edición. Ra-ma. 2009.

Jorge Badenas, José Luis Llopis, Óscar Coltell. "Cursopráctico de programación en C y C++". SegundaEdición. Publicacions de la Universitat Jaume I. 2001.

Bjarne Stroustrup. "The C++ Programming Language".Tercera Edición. Addison-Wesley. 1997. (Página webdel autor)

Bjarne Stroustrup. "El Lenguaje de programaciónC++". Edición Especial. Addison-Wesley. 2002.

http://www.research.att.com/~bs/3rd.html�

http://www.research.att.com/~bs/3rd.html�




Bibliografía

Stanley B. Lippman, Josée Lajoie. "C++Primer". Tercera Edición. Addison-Wesley.1998.

Enrique Hernández Orallo, José HernándezOrallo, Mª Carmen Juan Lizandra. "C++estándar. Programación con el Estándar ISO yla Biblioteca de Plantillas (STL)". Paraninfo.2002. (Página web del autor)

Luis Joyanes. "Programación en C++.Algoritmos, estructuras de datos y objetos".Segunda Edición. McGraw-Hill. 2006.

http://www.dsic.upv.es/~jorallo/libro_c++/�




“Aprendiendo UML En 24 Horas”, JosephSchmuller, Prentice Hall PTR, ISBN-13: 978-9684444638

“The Unified Modeling Language”, JamesRumbaugh, Ivan Jacobson, Grady Brooch,Addison-Wesley.

Bibliografía




1. INTRODUCCION AL DESARROLLO DE SISTEMAS

INFORMATICOS




AGENDA

Ingeniería del Software Ciclo de vida del Software Modelos de ciclo de vida para el desarrollo




Definición de Software

Para nosotros será el conjunto de información:– capaz de producir en las máquinas el comportamiento

deseado, de forma eficaz y eficiente,– para que los usuarios puedan utilizar el sistema de

forma eficiente.– al que los desarrolladores puedan dar mantenimiento

de forma eficaz y eficiente.




La Importancia del Software

Nuestra sociedad depende en gran medida de lainformática.– Parece impensable que los sistemas informáticos

dejasen de trabajar, ya que son soporte de muchossistemas.

– Ejemplos de sistemas básicos son: El sistema de control de los semáforos de la ciudad Sistemas de transporte aéreo Sistemas bancarios Sistemas de producción (fabricas), hospitales UVI,

etc..




¿Por qué es difícil desarrollar Software?

Lo cierto es que muchos proyectos de desarrollode software fracasan

Escalabilidad y complejidad Centraremos el tema mediante:

– Una estadística realizada sobre 8 proyectos deSoftware Estadounidenses.

– Características del Software.– Aplicaciones del Software.




Estadística

Realizada sobre 8 proyectos de Software Estadounidenses




Características del Software

Es inmaterial e invisible. El comprador lo puede evaluar cuando ya ha

sido construido. El Software se desarrolla, no se fabrica. Es complejo. Los sistemas actuales están

formados por miles de funciones con interfacescomplejas entre ellas.




El Software se desarrolla, no se fabrica.

En cualquier sistema de producción podemosobservar dos fases: la de desarrollo y la defabricación.

El desarrollo es lento y costoso. La fabricación es en serie y con costes estables.

Con el Software ocurre lo mismo pero ... Muchas aplicaciones se desarrollan a medida, sin

usar componentes existentes. La fabricación no se considera tal. Fase de pruebas/test




Aplicaciones del Software

Clasificación según:– La utilización que se hace de él.– El tratamiento comercial que tiene.– La funcionalidad que aporta a la máquina.– La exigencia en eficiencia y los factores críticos que

se le exigen. Requisitos



Mohamed Abderrahim, Universidad Carlos III de MadridAplicaciones del Software

Según la utilización del software:

De Gestión.– Se trata del software que da soporte a los procesos

comerciales y manejo de información que tienen porobjetivo permitir a las empresas una mejor gestión.

Producción y control de procesos.– Es el software que da soporte a los procesos productivos y

conducentes a desarrollar las actividades propias de cadanegocio.

Robótica.– Software que se centra en controlar y automatizar el

comportamiento de sistemas electro-mecánicos quecolaboran con los seres humanos en diversos campos,desde la ortopedia hasta la exploración de otros planetas.




De Ingeniería y Científico.– Da soporte a los procesos creativos y de diseño de las

personas, se caracteriza por cálculos matemáticoscomplejos. Ejemplo de ello son las herramientas CADo el soporte a seguimiento de acontecimientos en elespacio (Telescopios, etc.)

Ofimático.– Software que permite a las personas utilizar los

ordenadores en las tareas que habitualmente serealizan en oficinas.






Formación y divulgación.– Software que tiene por objetivo el transferir

conocimientos al ser humano, en esta categoría entrantoda la creación de cursos, simuladores,…

Domótico.– Software que se utiliza para controlar el hábitat del

ser humano, a pequeña escala. Va desde las alarmashasta el control de temperaturas de un hogar.

Ocio y Juegos.– Aplicaciones que tienen por objetivo el que el ser

humano pase algo de tiempo disfrutando con losordenadores.






Según el tratamiento comercial que tiene

Software de estantería: COTS (Commercial offthe shelf) - Software reutilizable desde un tercero

Paquetes parametrizables– > El usuario los adapta

Software a medida– > Específico para el usuario desde una tercera persona

Software personal– > Hecho para una tarea específica por el usuario




Funcionalidad que aporta a la máquina:

Software de sistemas– Ej. control de un proceso productivo

Comunicaciones– Ej. Chats, navegadores, control de puertos …

Empotrado– Ej. Ordenadores de abordo de un vehículo

De usuario– Ej. GUIs, Juegos, etc…




Exigencia en eficiencia y factores críticos

Software de tiempo real– Requerimientos de alto rendimiento, respuesta rápida.

Transaccional– Alta seguridad

Monousuario y PC– Manejo de cuentas de usuario, etc…




Ingeniería de Software

"Es el establecimiento y uso de principios(métodos) sólidos de ingeniería con el fin deobtener sistemas programados de formaeconómica, confiable y que trabajen en máquinasreales [computadores]" F.L. Bauer, 1972.

“La aplicación práctica del conocimientocientífico en el diseño y construcción deprogramas para computadores y ladocumentación asociada requerida paradesarrollarlos, operarlos y mantenerlos". B.Boehm, 1976.

Ingeniería

Software




Ingeniería de Software: origen

Su origen se debe a que el entorno de desarrollode sistemas software adolecía de:– Retrasos considerables en la planificación– Poca productividad– Elevadas cargas de mantenimiento– Demandas cada vez más desfasadas con las ofertas– Baja calidad y fiabilidad del producto– Dependencia de los realizadores




Ingeniería de Software: crisis del software

Primera Fase. Los albores (1945-1955)– Programar no es una tarea diferenciada del diseño de una máquina– Uso de lenguaje máquina y ensamblador

Segunda Fase. El florecimiento (1955-1965)– Aparecen multitud de lenguajes– Era posible hacer casi todo

Tercera Fase. La crisis (1965-1970)– Desarrollo inacabable de grandes programas– Ineficiencia, errores, coste impredecible– Nada es posible

Cuarta Fase. Innovación conceptual (1970-1980)– Fundamentos de programación– Verificación de programas– Metodologías de diseño

Quinta Fase. El diseño es el problema (1980-?)– Entornos de programación– Especificación formal– Programación automática




Ingeniería de Software: crisis del software

Ello ha venido originado por una falta de:– Formalismo y metodología– Herramientas de soporte– Administración eficaz

Las nuevas metodologías suponen un enfoqueintegral del problema, abarcando todas las fases– "Ingeniería del Software”: el tratamiento sistemático

de todas las fases del ciclo de vida del software




Ciclo de Vida del Software

•Ciclo de vida del software: El periodo de tiempocomprendido desde la definición de los requisitoshasta el fin del su uso.

•Procesos: Actividades y tareas implicadas en eldesarrollo operación y mantenimiento de unsistema de software.

•La aplicación de los procesos, tanto en eldesarrollo como en el posterior mantenimiento yoperación del software, se dibuja a través de unos“patrones fijos” que configuran el esquema demapa de situación, relación y continuidad entrelos diferentes procesos, actividades y tareas.




Modelos del Ciclo de Vida

Lineal o secuencial Cascada Evolutivo Espiral Incremental




Modelos del Ciclo de VidaLineal o secuencial

Lineal o secuencial

Requisitos

Diseño

Codificación

Pruebas

Integración

Operación y mantenimiento

Sucesión escalonada de las etapas que lo componen: requisitos, diseño, codificación, pruebas e integración.





Es necesario terminar por completo cadaetapa para pasar a la siguiente

Este modelo, identificado ya a principios dela década de los 50, resulta muy rígidoporque cada fase requiere como elemento deentrada el resultado completo de la anterior

– No hay Realimentación!!!

Requisitos

Diseño

Codificación

Pruebas

Integración






En situaciones reales su rigidez genera problemas:– Ej: Dificultad para disponer de requisitos completos o del diseño

pormenorizado del sistema en las fases iniciales, creando unabarrera que impide avanzar o mejorar el sistema en desarrollosfuturos.

Resulta apropiado para:Desarrollar nuevas versiones de sistemas ya veteranos

en los que el desconocimiento de las necesidades delos usuarios, o del entorno de operación no planteariesgos.Sistemas pequeños, sin previsión de evolución a corto

plazo.




Modelos del Ciclo de VidaCascada

Cascada

Requisitos

Diseño

Codificación

Pruebas

Integración


El modelo en cascada refleja la necesidad impuesta por la realidad de retornar con frecuencia desde una fase hacia las anteriores con la información generada al avanzar el desarrollo.





Cascada

Requisitos

Diseño

Codificación

Pruebas

Integración






Dos representaciones– La primera parece indicar que el retorno posible se da solamente entre

una fase y la anterior.– Mientras que en la segunda se refleja mejor el hecho de que en

cualquier fase puede surgir un retorno para modificar cualquiera de lasanteriores.

Este modelo reconoce la importancia de disponer de unosrequisitos y un diseño previo antes de comenzar con lacodificación del sistema





De nuevo: disponer de documentación elaborada de requisitosy diseño antes de empezar a codificar puede actuar como unabarrera que bloquee el comienzo de la siguiente fase

El modelo no se ha hecho muy popular, y los equipos que loaplican pueden caer en la tentación de comenzar con el diseñoo incluso con la codificación, sin tener un conocimientosuficiente de los requisitos.

Resulta apropiado para:Desarrollar nuevas versiones de sistemas ya veteranos en los que

el desconocimiento de las necesidades de los usuarios, o delentorno de operación no plantean riesgos.Sistemas pequeños, sin previsión de evolución a corto plazo.




Modelos del Ciclo de VidaEvolutivo

Este modelo está compuesto por varios ciclos de desarrollo. Cadauno de ellos produce un sistema completo con el que se operará en elentorno de operación.

La información acumulada en el desarrollo de cada sistema, ydurante su fase de operación sirve para mejorar o ampliar losrequisitos y el diseño del siguiente.

En realidad es un ciclo de vida común a todos los sistemasdesarrollados que se mejoran a través de versiones sucesivas.

Evolutivo

Diseño Codificación Pruebas Integración OperaciónMantenim. SistemaRequisitos


Diseño …Requisitos




Modelos del Ciclo de VidaEvolutivo

Las circunstancias en las que este modelo puede resultar apropiado son Desconocimiento inicial de todas las necesidades operativas que serán precisas,

generalmente por tratarse del desarrollo de un sistema que operará en un entornonuevo sin experiencia previa. Necesidad de que el sistema entre en operación en tiempos inferiores a los que

serían necesarios para diseñarlo y elaborarlo de forma exhaustiva. Necesidad de desarrollar sistemas en entornos cambiantes (sujetos a normas

legislativas, mejora continua del producto para hacer frente a desarrollos de lacompetencia, etc.).

Aunque en su concepción inicial contempla desarrollos internos en cascada,también podría plantearse, por ejemplo, un ciclo de vida evolutivo condesarrollos internos en espiral.

Evolutivo



Diseño …Requisitos




Modelos del Ciclo de VidaEspiral

Espiral

PROTOTIPOPROTOTIPO

PROTOTIPOOPERATIVO

ANÁLISIS DERIESGOS

ANÁLISIS DERIESGOS

ANÁLISIS DERIESGOS

DISEÑODETALLADO

IMPLEMEN-TACIÓN

VERIFICACIÓN

PRUEBASINTEGRACIÓN

PRUEBAS

CODIFICACIÓN

REQUISITOSDE

SOFTWARE

VALIDACIÓNDE

REQUISITOS

PLAN DEDESARROLLO

PLAN DEINTEGRACIÓN

Y PRUEBAS

DESCRIPCIÓNDE SISTEMA

REQUISITOSPLAN CICLO

DESARROLLO

DETERMINAROBJETIVOS,

ALTERNATIVAS YRESTRICCIONES

EVALUARALTERNATIVAS,IDENTIFICAR Y

RESOLVER RIESGOS

PLANIFICAR FASESSIGUIENTES

DESARROLLAR YVERIFICAR EL

SIGUIENTE NIVEL

DISEÑO DELSOFTWARE

VALIDACIÓN YVERIFICACIÓNDEL DISEÑO

SIMULACIONES, MODELOS

COSTE ACUMULADO





Definido por Boehm en 1988,– Desarrollo evolutivo, en contraste a la linealidad de los anteriores.– Introduce como elemento distintivo la actividad de “análisis de riesgo”

para guiar la evolución del proceso de desarrollo.

El ciclo de iteración: una espiral:– Al representarse sobre ejes cartesianos muestra en cada cuadrante una

clase particular de actividad: Planificación, Análisis de riesgo, Ingeniería y Evaluación,

– Estas actividades pueden suceder de forma consecutiva a lo largo delciclo de vida del desarrollo.

– La dimensión angular representa el avance relativo en el desarrollo delas actividades de cada cuadrante.

– En cada ciclo de la espiral se realiza una parte del desarrollo total, através de los cuatro tipos de actividades.





En la planificación de cada vuelta se establece elcontexto del desarrollo y se decide qué parte delmismo se abordará en el ciclo siguiente.

Las actividades de análisis de riesgo evalúan lasalternativas posibles para la ejecución de lasiguiente parte del desarrollo, seleccionando lamás ventajosa y previendo los riesgos posibles.

Las actividades de ingeniería corresponden a lasindicadas en los modelos lineales (secuencial ycascada): análisis, diseño, codificación, etc





Las actividades de evaluación analizan los resultados dela fase de ingeniería, tomando el resultado de laevaluación como punto de partida para el análisis de lasiguiente fase.

Este modelo permite múltiples combinaciones ya que enla planificación de cada ciclo se determina el avance quese va a ejecutar durante la vuelta. Éste puede consistir enla obtención y validación de requisitos, o en el desarrollodel diseño, o el diseño junto con la codificación, o en laobtención de un subsistema completo (cascada derequisitos – diseño – codificación – pruebas –integración).




Modelos del Ciclo de VidaIncremental

Incremental

RE

QU

ISIT

OS Diseño Codificación Pruebas Integración Operación

Mantenim. Sub-sistema

Diseño Codificación Pruebas Integración OperaciónMantenim. Sub-sistema

Diseño Codificación Pruebas …

SISTEMA

El modelo incremental mitiga la rigidez del modelo en cascada, descomponiendo el desarrollo de un sistema en partes; para cada una de las cuales se aplica un ciclo de desarrollo (en cascada en la representación gráfica).





Ventajas :El usuario dispone de pequeños subsistemas operativos que

ayudan a perfilar mejor las necesidades reales del sistema en suconjunto.El modelo produce entregas parciales en periodos cortos de

tiempo, comparados con el tiempo necesario para la construccióndel sistema en su conjunto, y permite la incorporación de nuevosrequisitos que pueden no estar disponibles o no ser conocidos aliniciar el desarrollo.





Aunque en la representación gráfica de la figura anterior,los desarrollos de cada subsistema se solapan en eltiempo, en su aplicación real, el segundo y siguientessubsistemas pueden comenzar una vez concluido elanterior.

Resulta apropiado:– Desarrollo de sistemas en los que el cliente necesita disponer de

parte de la funcionalidad antes de lo que costaría desarrollar elsistema completo.

– Desarrollo de sistemas en los que por razones del contextointeresa realizar la obtención de los requisitos de formaescalonada a través de subsistemas.




Prototipos

El prototipado consiste en la construcción de modelos de prueba,que simulen el funcionamiento que se pretende conseguir en elsistema.

Los prototipos pueden ser:Ligeros: dibujos de pantallas de interfaz con simulación de

funcionamiento por enlaces a otros dibujos…Operativos: Módulos de software con funcionamiento propio que se

desarrollan sin cubrir las funcionalidades completas del sistema,normalmente en entornos RAD (”rapid application development”).

Esta forma de trabajo previo suele tener como principal objetivo laexperimentación con un entorno similar al pretendido, para obtenerretro-información del usuario o cliente que ayuda a losdesarrolladores en la concreción de los requisitos.




Prototipos

Aunque ofrece muchas ventajas, deben conocerse los riesgos queimplica el uso de prototipado:Como puede parecer que se ha desarrollado un interfaz de

usuario sofisticado y elaborado, el cliente puede llegar a pensarque ya se ha realizado el grueso del trabajo.Si se trata de un prototipo operativo, puede empezar a crecer al

margen de la planificación, más allá de los objetivos previstos,desbordando agendas y recursos.Si se trata de un prototipo ligero desarrollado fuera del

departamento de desarrollo (ej. Marketing), puede mostrar alcliente funcionalidades no implementables.El prototipo puede llegar a ofrecer funcionalidades superiores a

lo conseguible, por estar construido en un entorno diferente al dedesarrollo, o no incluir toda la funcionalidad del sistema.




Proceso Unificado de Desarrollo

Propuesto por los autores de UML (lenguajeunificado de desarrollo)

Basado en componentes interconectados a travésde interfaces

Utiliza UML para desarrollar los esquemas ydiagramas de un sistema software

Principales aspectos definitorios– dirigido por casos de uso– centrado en la arquitectura– iterativo e incremental




Caso de uso: Fragmento de funcionalidad queproporciona al usuario un resultado importante

Modelo de casos de uso: Funcionalidad total delsistema– ¿Qué debe hacer el sistema … para cada usuario?– Guían el proceso de desarrollo





Centrado en la arquitectura– Describe diferentes vistas del sistema– Incluye los aspectos estáticos y dinámicos más significativos– Es la forma del software– La arquitectura y los casos de uso evolucionan en paralelo– Responsable: el arquitecto

Empieza por la parte que no es específica de los casos de uso Trabaja con casos de uso claves Progresa con la especificación de más casos de uso





Iterativo e incremental– Se divide el trabajo en mini-proyectos– Cada mini-proyecto es una iteración que resulta en un

incremento– La iteración

Trata un conjunto de casos de uso Trata los riesgos más importantes

– En cada iteración se persiguen unos objetivosconcretos

– Ejemplo de iteración: 2 a 6 semanas





Beneficios de un proceso iterativo controlado:– Coste del riesgo a un solo incremento– Reduce el riesgo de no sacar el producto en el

calendario previsto– Acelera el ritmo de desarrollo– Se adapta mejor a las necesidades del cliente


0. presentación

Documents