introducción a la ingeniería de software:qué es un buen sistema?

1

Introducción a la Ingeniería de Software:Qué es un Buen Sistema?

Adaptado de http://comunidad.uach.mx/fmarisc/analisis/Analisis.ppt

2

Ingeniería de Software

¿Qué es un BUEN SISTEMA?Un buen sistema (o uno de alta calidad) es

aquél que cumple con las necesidades del cliente. El sistema debe ser:

UTIL y UTILIZABLE: Un buen software hace más fácil o mejor la vida a las personas.

CONFIABLE: Un buen software tiene pocos errores. FLEXIBLE: Las necesidades cambian con el tiempo, aún

cuando el software se está desarrollando, entonces es importante poder hacer cambios posteriores al software. Debe podérsele dar mantenimiento después de liberado.

3


¿Qué es un BUEN SISTEMA? FLEXIBLE: Las necesidades cambian con el tiempo, aún

cuando el software se está desarrollando, entonces es importante poder hacer cambios posteriores al software. Debe podérsele dar mantenimiento después de liberado.

ACCESIBLE: tanto para comprar como para mantener. Debe ser razonablemente fácil y rápido poderlo desarrollar o darle mantenimiento.

DISPONIBLE: De otra forma no importa que tan bueno es. Debe ser capaz de ejecutarse el el hardware disponible y con el sistema operativo disponible, etc. Debe existir y entregarse el software prometido.

4


¿Tenemos buenos sistemas? Existen avances satisfactorios en sistemas de

software modernos: contabilidad, bancos, búsqueda de información, etc. Lo que indica que estamos haciendo las cosas correctamente.

5


Problemas:Hay sistemas que no cumplen con las

necesidades de los usuarios y/o tienen fallas técnicas.

Generalmente, los sistemas no están actualizados ni cuando se están diseñando.

6


Problemas:Aún existe el “error de la computadora” como

excusa a un mal servicio a los clientes.La mayoría de los usuarios de PCs esperan

que sus aplicaciones y aún el sistema operativo se “caiga” o “congele” de vez en cuando.

7


Problemas:EL SOFTWARE NO SIEMPRE ES

UTILIZABLE, ÚTIL, CONFIABLE O DISPONIBLE.

La falta de FLEXIBILIDAD también resulta evidente, como lo muestran el problema del milenio y la adecuación de todos los sistemas viejos (legacy) a procesos de negocios cambiantes.

8


Problemas:La COSTEABILIDAD se relaciona mucho con

la confiabilidad y la flexibilidad debido a que el costo de corregir y mantener es el más alto costo asociado con el software

9


Problemas aún más drásticos.A veces las fallas en algunos de los atributos

deseables de los sistemas han provocado catástrofes como las siguientes:

Ariane 5: Fallas de software hacen explotar la nave (1996)

Taurus: Mercado accionario londinense no pudieron terminar proyecto de software y tuvieron grandes pérdidas (1993)

10


Problemas aún más drásticos. Manejo de maletas de Denver: Fallas del sistema

y el alto costo de corregirlo, no permitía al aeropuerto abrir a tiempo.

Sistema de Ambulancias de Londres: Fallas de diseño y de ejecución provocaron la muerte de gente por falta de ambulancias (1992)

Therac-25: Sobredosis radioactivas por fallas en el software de la máquina a varias personas (1987)

11


Problemas aún más drásticos.Según W. Wayt Gibbs en Software’s chronic

crisis. Scientific American (International Ed.) pp 72-81, Sep. 1994. dice:

En promedio, los proyectos grandes toman 50% más de tiempo de lo planeado;

75% de los proyectos grandes tienen fallas operacionales;

25% de los proyectos grandes son cancelados

12


Promesas, promesasCada nueva tecnología promete reducir los

tiempos de desarrollo e incrementar los promedios de éxito de los proyectos.

Todos lo dudamos.

13

Ingeniería de Software Promesas, promesas

Según Frederick P. Brooks (The mythical man-month, Addison-Wesley 1975/1995), mientras más grande sea el proyecto, mayor será la proporción del costo y tiempo del proyecto gastado en la comunicación entre la gente del proyecto, porque cada persona tiene más gente con quién comunicarse. Cuando un proyecto empieza a quedarse atrás en el tiempo, el poner más gente por lo general falla.

14

Ingeniería de Software Promesas, promesas

El Departamento de Defensa de EU, intentó resolver la crisis del software y comisionó el diseño del lenguaje de programación ADA, el cual se estandarizó en 1983, el cual soportaba lo mejor de los conceptos de análisis, diseño y programación estructurados, la modularidad y la encapsulación fueron conceptos clave en el diseño del lenguaje, pero aún esta enorme inversión ha fracasado.

15


¿Cómo son los sistemas considerados buenos?El problema fundamental para comprenderlos

es: Hay un límite de cuánto puede entender un

humano en un momento dado

16


¿Cómo son los sistemas considerados buenos?Los sistemas pequeños, son realizados

mediante “programación heroica” en la cual una sola persona pretende recordar todo lo relevante acerca del sistema. Pero en general esto es imposible.

17


¿Cómo son los sistemas considerados buenos?La evolución del entendimiento de un

problema seria como sigue: 1.- Los sistemas son muy complejos y no se

puede centrar solo en el código cercano al cambio por realizar sino que se debe entender partes más lejanas.

18


¿Cómo son los sistemas considerados buenos?

2.- Un sistema es un conjunto de módulos y existen algunas dependencias entre ellos. En el sentido más general, un módulo puede ser cualquier “bit” identificable de un sistema por lo cual tiene sentido considerarlo en forma separada.

19


¿Cómo son los sistemas considerados buenos?

Los módulos pueden ser: Archivos Subrutinas Funciones de biblioteca Clases, en un lenguaje orientado a objetos. Otras partes conocidas como módulos o similares Programas o subsistemas independientes o semi-

independientes.

20


¿Cómo son los sistemas considerados buenos? (cont.)Características de los módulos para que el

desarrollo y mantenimiento del sistema sea lo más fácil, barato y confiable posible:

dependencia (dependency) cohesión (cohesion) Alta

21


¿Cómo son los sistemas considerados buenos? (cont.)

interfase (interface) Definida Encapsulación (encapsulation) Módulos abstracción (abstraction) Componente (component)

Insertable, reusable Acoplamiento (coupling) Bajo

22

Ingeniería de SoftwareSi El módulo A depende del módulo B si un cambio

en el módulo B significa que el módulo A también necesita ser modificado.

La dependencia es conocida a veces como acoplamiento. Un sistema con muchas dependencias tiene un acoplamiento grande.

Los sistemas buenos tienen un acoplamiento bajo, porque los cambios a una parte del sistema son menos propensos a propagarse a través del sistema

23


Encapsulamiento: Acoplamiento bajoQueremos minimizar el numero de casos en

los cuales un cambio a un módulo genera un cambio en otro módulo.

Tenemos que conocer cuales cambios dentro de un módulo pueden afectar el resto del sistema.

24


Encapsulamiento: Acoplamiento bajoPara tomar ventaja del acoplamiento bajo de

un sistema, es importante ser capaz de identificar cuales módulos están acoplados, de otra forma se tendrá que gastar esfuerzo verificando si hay que hacer cambios a un módulo, lo cual es un costo aún cuando no fue necesario el cambio. Nos gustaría tener certeza sobre los cambios.

25

Ingeniería de Software Encapsulamiento: Acoplamiento bajo

Una vez que las fronteras entre los módulos de nuestro sistema están definidas, hay dos clases de información que puede ser útil:

1.- ¿Qué suposiciones de un módulo dado pueden los clientes hacer acerca de él? Contestando, nos permitirá conocer que clase de cambios a un módulo pueden ser peligrosos (servicios que provee?)

26

Ingeniería de Software Encapsulamiento: Acoplamiento bajo

2.- ¿Cuáles módulos son clientes de un módulo dado? Contestando, nos dice cuáles módulos tendrán que cambiar, si hacemos un cambio peligroso a un módulo.

27


Encapsulamiento: Acoplamiento bajo (Cont.) Interfases

Una interfase a un módulo define algunas características del módulo sobre las cuáles sus clientes pueden depender.

28



El resto del sistema solo puede usar el módulo en formas permitidas por las interfases; esto es, una interfase ENCAPSULA el conocimiento acerca de los módulos. “Las conexiones entre módulos son las suposiciones que hacen los módulos unos acerca de otros”

29



Cualquier suposición que un cliente hace acerca de un servidor corre el riesgo de ser incorrecta; entonces debemos documentar tales suposiciones en interfases y verificar su validez.

30



Si documentamos bien todas las suposiciones en la interfase, seremos capaces de decir: “Si un módulo cambia internamente sin cambiar su interfase, este cambio no necesitará otros cambios en otras partes del sistema”.

31



Idealmente debería haber una verificación automática de que otros módulos no hacen suposiciones que no están documentadas en esta interfase, y también de que el módulo siempre justifica las suposiciones que están documentadas.

32



En un lenguaje de programación, mientras más permita que esas verificaciones sean automáticas, se dice que más soporta la modularidad y la encapsulación.

33


Encapsulamiento: Acoplamiento bajo (Cont.)Dependencias del contexto

Existen varias razones para querer conocer no solo qué dependencias pudieran existir (esto es, qué características están documentadas en las interfases de los módulos del sistema) sino también qué dependencias existen realmente.

34



Sabemos que un cambio en un módulo puede afectar a sus clientes; sus clientes (por definición) son aquellos módulos que pueden necesitar un cambio, entonces es importante ser capaz de decir cuáles son ellos.

35

Ingeniería de Software Encapsulamiento: Acoplamiento bajo (Cont.)

Dependencias del contexto Suponga que quiere reusar un módulo. Es necesario

saber no solo qué servicios provee (cual es su interfase) sino también qué servicios requiere para trabajar. Los servicios que un módulo requiere son llamados sus dependencias de contexto. Ellos pueden a su vez ser expresados en términos de interfases; el módulo puede garantizar que si ciertas interfases le son provistas, entonces él a su vez proveerá sus propias interfases.

36



Entre ellos, las dependencias de contexto de un módulo y la propia interfase del módulo garantiza que proveerá los servicios descritos en su interfase.

37


Encapsulamiento: Acoplamiento bajo (Cont.)Beneficios de la modularidad con interfases

definidas. Aún una interfase muy pobre para un módulo

incorrectamente seleccionado puede hacer a un sistema más fácil de entender y modificar. Porqué?

38


Cualquier elemento que reduzca lo que tiene que ser conocido acerca de un módulo es benéfico en varias formas:

En un equipo de desarrollo, la gente desarrollando código que usa un módulo, solo deberá entender la interfase del módulo, no cómo trabaja, entonces serían más productivos.

Debido a que los desarrolladores pueden ignorar en forma segura algunos aspectos del sistema, tendrán un mejor entendimiento de los aspectos que sí necesitan conocer, entonces se introducirán menos errores.

39


Los errores deberán ser más fáciles de encontrar (en desarrollo y mantenimiento), porque se evitará el examinar módulos irrelevantes.

Una vez que existe un módulo, con documentación de lo que provee y lo que requiere, es posible considerar reusarlo.

El reto real, es definir buenos módulos con las cosas correctas en sus interfases. Solo entonces se pueden lograr los beneficios completos.

40


Encapsulamiento: Acoplamiento bajo (Cont.)Un módulo puede tener varias interfases

A veces es necesario documentar los servicios que un módulo provee con varias y diferentes interfases, de un modo que podamos ser más precisos acerca de que servicios un cliente dado necesita. Esto es a la vez útil para el mantenimiento y para el reuso.

41


Encapsulamiento: Acoplamiento bajo (Cont.)

Ya tenemos una respuesta parcial a la pregunta de ¿Cómo son los sistemas considerados buenos?

Un buen sistema consiste de módulos encapsulados

42

Ingeniería de Software Abstracción: Alta Cohesión.

Los buenos módulos tienen la propiedad de que sus interfases proveen una abstracción de alguna cosa que se entiende intuitivamente la cual sin embargo puede ser compleja de implantar. Tales módulos se dice que tienen una alta cohesión.

La interfase realiza una abstracción de las cosas que el desarrollador no tiene que entender para usar el módulo, dejando una figura coherente de lo que el usuario de un módulo quiere conocer.

43


Abstracción: Alta Cohesión. El desarrollador está protegido de información

irrelevante acerca de cómo el módulo hace lo que hace. Esta preocupación de permitir al desarrollador concentrarse en lo esencial es ligeramente diferente a la preocupación de encapsulación para lograr un acoplamiento bajo, lo cual va dirigido a la prevención de que el desarrollador use información escondida.

44


Abstracción: Alta Cohesión. Abstracción es cuando un cliente de un módulo

no necesita saber más de lo que está en la interfase.

45


Encapsulación es cuando un cliente de un módulo no es capaz de conocer más de lo que está en la interfase. Si un módulo, de cualquier tamaño y complejidad, es

una buena abstracción (tiene una alta cohesión y un acoplamiento bajo) puede ser factible de reusarlo en posteriores sistemas, o de reemplazo en sistemas ya existentes.

Estaríamos hablando de un componente insertable o conectable (“pluggable component”)

46


Arquitectura y componentesLa arquitectura donde se desarrolla y aquella

dónde se va a usar.En los 80s y principios de los 90s, la

tecnología orientada a objetos iba a ser la solución a la crisis en desarrollo de software.

47


Arquitectura y componentesComponente

Es una cosa que se puede reusar o reemplazar

Desarrollo Basado en Componentes (CBD, Component Based Development)

Un módulo con propiedades que lo hacen reusable y reemplazable.

48


Arquitectura y componentes ¿Qué determina cuando un módulo es reusable?

Tiene una cohesión alta Acoplamiento bajo con el resto del sistema Interfase bien definida Abstracción encapsulada de una cosa bien entendida

49


Arquitectura y componentes Si un módulo es reusable depende del contexto en

que se desarrolló y en el cual va a ser reusado. Ejemplo de un factor no técnico de reuso:

Recompensar al programador por el número de líneas que escriben.

Los factores técnicos involucran decisiones de arquitectura y más alto nivel.

50


Diseño basado en componentes: Insertabilidad, conectabilidad (pluggability)La forma ideal de construir un nuevo sistema

es tomar algunos componentes existentes y juntarlos.

51


Diseño basado en componentes: Insertabilidad, conectabilidad (pluggability)Los componentes tienen que ser partes que

llenan o cumplen necesidades en un sistema completo.

Las partes tienen que ser compatibles unas con otras y eso depende de la presencia de una arquitectura adecuada.

52


Diseño basado en componentes: Insertabilidad, conectabilidad (pluggability)Las decisiones importantes acerca de la

arquitectura: Deben ser tomadas lo más pronto en el proyecto. Son afectadas por la naturaleza de los componentes

en la arquitectura Pueden ser influenciadas por el medio ambiente del

proyecto

53


¿Cómo se construyen los buenos sistemas?Usar un PROCESO definido con FASES

claras, cada una de las cuales tiene un PRODUCTO FINAL (puede ser un documento o tal vez un prototipo)

54


¿Cómo se construyen los buenos sistemas?Preocuparse por cumplir con un conjunto

claro de requerimientos, que se definen tan pronto como sea posible

Preocuparse por formas de verificación y validación, tan esenciales como construir el producto en sí mismo.

55


¿Cómo se construyen los buenos sistemas?Usar un almacén de CONOCIMIENTOS,

ARQUITECTURAS y COMPONENTES relevantes.

Hacer un uso sensible de herramientas.

56

Proceso de desarrolloMétodo tradicional para el desarrollo de

Sistemas (Cascada / Waterfall)


Análisis

Diseño

Implementación

Pruebas

Mantenimiento

57

Proceso de desarrollo

Cada fase se realiza hasta que se completó la anterior. Supone que no se vuelve a entrar en las fases terminadas.


Análisis

Diseño

Implementación

Pruebas

Mantenimiento

58

Ingeniería de Software Proceso de desarrollo

Administración de riesgos implica: 1.- Cada vez que se toma una decisión se tiene el riesgo de

que sea incorrecta. Mientras más se tarde en detectar un error más difícil es corregirlo. Evaluaciones frecuentes ayudan a corregir.

2.- Un riesgo mayor es que los desarrolladores malinterpreten los requerimientos. La elaboración de prototipos permite reafirmarlos.

59

Proceso de desarrollo Espiral de desarrollo:

Metodología Unificada. Gran cantidad de metodologías orientadas a objetos han salido

a la luz y las de Grady Booch, James Rumbaugh, Ivar Jacobson se unieron para formar el Lenguaje de Modelación Unificado (UML) y fue adoptado por el Object Management Group (OMG) como el estándar para cuestiones orientadas a objetos.


AnálisisDiseño

Construcción Transición

60

Bibliografía

BibliografíaUsing UML. Software Engineering with objects and Components

Perdita Stevens, Rob Pooley

Addison Wesley. Updated Edition 2000. http://www.dcs.ed.ac.uk/home/pxs/Book/

The Object-Oriented Thought Process

Matt Weisfeld Sams Publishing, 2000

Aprendiendo UML en 24 Horas Joseph Schmuller Editorial Prentice Hall, Primera Edición 1999

Advanced Object-Oriented Analysis & Design Using UML

James J. Odell Cambridge University Press. 1998

UML y Patrones. Introducción al análisis y diseño orientado a objetos.

Craig Larman Prentice Hall. 1999

Análisis y Diseño de Sistemas Kendall & Kendall Prentice Hall. Pearson Educación. Tercera Edición. 1995

UML gota a gota Martin Fowler con Kendal Scott

Addison Wesley. Pearson. 1999

introducción a la ingeniería de software:qué es un buen sistema?

Documents