Curso de Ingenieria de Software

Instituto Tecnolgico de Culiacn Ingeniera en Sistemas Computacionales Ingeniera de Software MC MARCO ANTONIO RODRIGUEZ AVILES
Enero-Jun 2014
1
UNIDAD I
Introduccin a la Ingeniera de Software
Introduccin
Es comn darse cuenta que la invencin de una tecnologa puede tener profundos efectos con otras tecnologas con las que en apariencia no tiene ninguna relacin. En la actualidad, el software de computadora es la tecnologa individual ms importante en el mbito mundial. Porqu? En la dcada de 1950 nadie podra haber predicho que el software: Se convertira en una tecnologa indispensable en los negocios, la ciencia y la ingeniera.
3
Introduccin
Permitira la creacin de tecnologas nuevas (ing. gentica). Permitira la expansin de tecnologas existentes (telecomunicaciones). Sera la fuerza conductora detrs de la revolucin de las computadoras personales. Tampoco nadie imagin que: Los productos empaquetados de software se podran comprar en el super. Una compaa de software se volvera ms grande y ms influyente que la mayora de las compaas de la era industrial. Una gran red construida con software (internet) cambiara todo desde la investigacin bibliogrfica hasta las compras de los consumidores y los hbitos diarios de los jvenes (y no tan jvenes)
Introduccin
Y la lista podra seguir. Por ltimo, nadie podra haber predicho que millones de programas tendran que corregirse, adaptarse y mejorarse conforme pasara el tiempo y que el desarrollar estas actividades de mantenimiento absorbera ms gente y recursos que todo el trabajo aplicado para la creacin de software nuevo.
Introduccin
En 1970 menos del 1 % de las personas podran haber definido lo que significaba software de computadora. En la actualidad, los profesionales y muchas otras personas creen que entienden el software. Pero, en realidad lo hacen? Que es el software ? Es la parte lgica de una computadora (programas). Conjunto de programas escritos para la computadora. Instrucciones que cuando se ejecutan proporcionan la funcin y el comportamiento deseado. Para entender el software se requiere ms que una definicin formal, debemos examinar las caractersticas que lo hacen diferente de otras cosas que el ser humano construye. El software es un elemento lgico y no fsico de un sistema.
6
Caractersticas diferentes del software con respecto al hardware

1.
2.
3.
4.
El software se desarrolla, no se fabrica en un sentido clsico. El software no se desgasta. La mayora del software se construye a la medida, en vez de ensamblar piezas existentes. El xito se mide por la calidad de una nica entidad.
Categoras del software
Software de sistemas. Software de aplicacin Software cientfico y de ingeniera. Software empotrado. Software de lnea de productos. Aplicaciones basadas en Web. Software de inteligencia artificial. Sin embargo han aparecido nuevos retos: Computacin ubicua Alimentacin de la red. Fuente abierta.
Preocupacin por la industria

En la actualidad la industria del software se ha convertido en u factor dominante en la economa del mundo industrializado. El programador solitario de antao ha sido sustituido por equipos de especialistas en software. Sin embargo an se hacen las siguientes preguntas:
9
Hacia la Ingeniera de Software

Por qu tarda tanto tiempo la obtencin del software terminado? Por qu son tan altos los costos de desarrollo de software? Por qu no podemos encontrar todos los errores antes de entregar el software al cliente? Por qu se gasta tanto tiempo y esfuerzo en el mantenimiento de los programas existentes? Por qu resulta difcil medir el progreso al desarrollar y darle mantenimiento al software?
10
Hacia la Ingeniera de Software

Estas y muchas otras preguntas demuestran la preocupacin de la industria por el software y por la manera en que ste se desarrolla. Esta preocupacin ha llevado a la adopcin de la prctica de la Ingeniera de software.
11
Algunas definiciones
Qu es Ingeniera? Aplicacin de los conocimientos cientficos a la invencin, perfeccionamiento y utilizacin de la tcnica industrial en todas sus ramas. Qu es ingeniera de software? El establecimiento y uso de principios slidos de ingeniera, para obtener econmicamente un software confiable y que funcione de manera eficiente en mquinas reales. [fritz Bauer]
12
Conceptos Generales
La ingeniera de software es la aplicacin de un enfoque sistemtico, disciplinado y cuantificable al desarrollo, operacin y mantenimiento del software.[IEEE93] La IS es la rama de la ingeniera que aplica los principios de la ciencia de la computacin y las matemticas para lograr soluciones costo-efectivas a los problemas de desarrollo de software.
13
Algunas definiciones
La IS permite elaborar consistentemente productos correctos, utilizables y costoefectivos. El proceso de software es un marco de trabajo para las tareas que se requieren en la construccin de software de alta calidad. Es lo mismo ingeniera de software y proceso de software?
14
Mitos del software
Mitos de la administracin. Los administradores con responsabilidades sobre el software, a menudo estn bajo presin por mantener los presupuestos, evitar que los itinerarios se extiendan y mejorar la calidad, por lo que con frecuencia los administradores se aferran a un mito si siente que esta creencia reducir la presin. Mito: Ya se tiene un libro lleno de estndares y procedimientos para la construccin de software. Esto proporcionar a mi gente todo el conocimiento necesario? Realidad: Tal vez sea verdad que el libro existe, pero se usa?, los encargados de la construccin de software saben de su existencia?, el libro refleja la practica moderna de la IS? est completo?, es adaptable?, est enfocado en la calidad? En muchos casos la respuesta a todas estas preguntas es no.
15
Mitos del software

Mito: si est atrasado el itinerario es posible contratar ms programadores para poder terminar a tiempo. Realidad: El desarrollo de software no es un proceso mecnico como la manufactura. Agregar gente a un proyecto de software atrasado lo atrasa ms segn Brooks. Cuando se agrega gente a un equipo que ya estaba trabajando se debe invertir tiempo en la enseanza de los recin llegados, lo cual reduce el tiempo dedicado al esfuerzo para el desarrollo productivo. Se puede agregar gente pero solo de una manera planeada y bien coordinada. Mito: si decido subcontratar el proyecto de software a un tercero, puedo relajarme y dejar que esa compaa lo construya. Realidad: Si una organizacin no entiende cmo administrar y controlar internamente los proyectos de software, invariablemente entrar en conflicto al subcontratar este tipo de proyectos.
16
Mitos del software
Mitos del cliente. Muchas veces, el cliente cree en mitos acerca del software porque los profesionales y administradores del software hacen muy poco para corregir la desinformacin. Los mitos conducen a expectativas falsas y en definitiva la insatisfaccin con el desarrollador: Mito: Un enunciado general de los objetivos es suficiente para comenzar a escribir los programas, los detalles se pueden afinar despus. Realidad: Un enunciado ambiguo de los objetivos es la receta perfecta para el desastre. Los requerimientos precisos (se derivan en forma iterativa) se consiguen mediante la comunicacin continua y efectiva entre el cliente y el desarrollador
17
Mitos del software

Mito: los requerimientos del proyecto cambian de manera continua, pero el cambio puede ajustarse con facilidad porque el software es flexible. Realidad: Es verdad que los requerimientos cambian, pero el impacto del cambio vara de acuerdo al momento en que ste se introduce. Es decir, conforme ms avanzado est el proyecto ms costoso ser realizar el cambio.
18
Mitos del software
Mitos del desarrollador. Estos mitos han permanecido a travs de poco ms de 50 aos de cultura de la programacin. Ya que en los primeros aos la programacin era vista como una forma de arte, las viejas formas y actitudes son difciles de eliminar. Mito: Una vez que el programa ha sido escrito y puesto a funcionar, el trabajo est terminado. Realidad: Mientas ms rpido se comience a escribir cdigo, ms tiempo pasar para que el programa est terminado. Los datos de la industria indican que entre el 60 y 80 por ciento del total del esfuerzo aplicado al software se realiza despus de que ha sido entregado al cliente por primera vez. Mito: Mientras que el programa no se est ejecutando, no existe forma de evaluar la calidad. Realidad: uno de los mecanismos ms efectivos para el aseguramiento de la calidad del software se puede aplicar desde el inicio de un proyecto (p.ej.: revisiones tcnicas formales).
19
Mitos del software
Mito: el nico producto del trabajo que puede entregarse para tener un proyecto exitoso es el programa en funcionamiento. Realidad: el programa en funcionamiento es slo una parte de la configuracin del software que incluye muchos otros elementos, por ejemplo la documentacin es fundamental para el xito del proyecto y, an ms importante, representa una gua para el mantenimiento del software. Mito: la IS obligar a emprender la creacin de un a documentacin voluminosa e innecesaria y esto tornar ms lento el proceso. Realidad: la IS no se refiere a la elaboracin de documentos. Est relacionada con la creacin de calidad. Una mejor calidad conduce a la reduccin de trabajos redundantes y esto resulta en menores tiempos de entrega.
20
Mtricas para la productividad y calidad del software

La medicin es fundamental para cualquier disciplina de ingeniera y la ingeniera de software no es una excepcin. Lord Kelvin dijo: Cuando puedes medir lo que ests diciendo y expresarlo en nmeros, sabes algo sobre ello; pero cuando no puedes medirlo, cuando no puedes expresarlo con nmeros, tu conocimiento es escaso e insatisfactorio En la ltima dcada la comunidad de la ingeniera de software ha comenzado a tomar en serio las palabras de Lord Kelvin.
21
Mtricas para la productividad y calidad del software

Las mtricas del software se refieren a un amplio elenco de medidas para el software. La medicin se puede aplicar al: Proceso del software, con el intento de mejorarlo sobre una base continua. Proyecto del software, para ayudar en la estimacin, en el control de calidad, la evaluacin de la productividad y el control de proyectos.
22
Medicin del software

La medicin es muy comn en el mundo de la ingeniera. Medimos potencias de consumo, pesos, dimensione fsicas, temperaturas, voltajes, seales de ruido, etc. Desgraciadamente la medicin se aleja de lo comn en ingeniera de software. Se dificulta ponerse de acuerdo sobre qu medir y cmo evaluar las medidas.
23

Razones para medir el software: 1. Para indicar la calidad del producto. 2. Para evaluar la productividad de la gente que desarrolla el producto. 3. Para evaluar los beneficios (calidad y productividad) derivados del uso de nuevos mtodos y herramientas de IS. 4. Para establecer una lnea de base para la estimacin. 5. Para ayudar a justificar el uso de nuevas herramientas.
24

Las mediciones del mundo fsico se engloban en dos categoras: Medidas directas: ejemplo la longitud de un tornillo. Medidas indirectas: ejemplo la calidad de los tornillos (% de tornillos rechazados). Las mtricas del software pueden ser catalogadas de forma parecida.
25
Medidas directas: del proceso de IS: costo y esfuerzo aplicado. del producto: tamao de la memoria, lneas de cdigo (LDC) producidas, velocidad de ejecucin, defectos encontrados en un perodo determinado. Medidas indirectas: funcionalidad, complejidad, eficiencia, fiabilidad, facilidad de mantenimiento, correctez, integridad, flexibilidad, facilidad de prueba, portabilidad, reusabilidad, facilidad de interoperacin, facilidad de uso.
26
Clasificacin de las mtricas del software
Mtricas de productividad: se centran en el rendimiento del proceso de la IS. Mtricas de calidad: proporcionan una indicacin de cmo se ajusta el software a los requisitos implcitos y explcitos del cliente Mtricas tcnicas: se centran en las caractersticas del software (complejidad lgica, grado de modularidad).
27
Medida de calidad
Existen muchas medidas de calidad de software, entre las cuales tenemos las siguientes: Correccin: Es el grado con que el software realiza la funcin requerida. La medida ms comn de la correccin es el nmero de defectos por KLDC, donde defecto se define como una falta verificada de conformidad con los requisitos. Facilidad de mantenimiento: es la facilidad con la cual se puede corregir un programa si se encuentra un error, adaptarlo si su entorno cambia, o mejorarlo si el cliente desea un cambio en los requisitos. El mantenimiento representa ms esfuerzo que cualquier otra actividad del la IS. No hay forma de medir directamente la facilidad de mantenimiento, por lo tanto se deben utilizar medidas indirectas. Por ejemplo una mtrica orientada al tiempo es el tiempo medio del cambio (TMC), esto es el tiempo que se tarda en analizar la peticin de cambio, en disear una modificacin adecuada, en implementar el cambio, en probarlo y en distribuir el cambio a todos sus usuarios.
28
Medida de calidad
Integridad: En esta poca de intrusos informticos y virus, la integridad del software ha tomado mucha importancia. Este atributo mide la habilidad de un sistema para resistir ataques ( tanto accidentales como intencionados) contra su seguridad. El ataque se puede realizar en cualquiera de los tres componentes del software: programas, datos y documentos. Facilidad de uso: la facilidad de uso es un intento por cuantificar lo amigable que puede ser con el usuario y y se puede medir en funcin de 4 caractersticas: 1. Habilidad intelectual y/o fsica requerida para aprender el sistema. 2. El tiempo requerido para llegar a ser eficiente en el uso del sistema. 3. Aumento neto en productividad (sobre el enfoque que el sistema reemplaza) 4. Valoracin subjetiva de la disposicin de los usuarios hacia el sistema 29 Con frecuencia un programa que no es fcil de usar est condenado
Unidad II
Requisitos de Software
30
Introduccin
La comprensin de los requisitos de un problema est entre las tareas ms difciles que enfrenta un ingeniero de software. An cuando los clientes y usuarios finales son explcitos en sus necesidades, estos requisitos pueden cambiar durante el proyecto. Por lo que la ingeniera de requisitos (IR) es difcil. La IR es una accin de la ingeniera del software que comienza durante la actividad de comunicacin y contina en la actividad de modelado. Es esencial que el equipo de desarrollo del software haga un esfuerzo real por entender los requisitos de un problema antes de intentar resolverlo.
31
Introduccin
La ingeniera de requisitos tiende un puente hacia el diseo y construccin. El trabajo a lo largo del puente se inicia en la parte alta del proyecto lo que permite que el equipo de software examine:
el contexto del trabajo de software que ser realizado, Las necesidades especficas que el diseo y construccin deben abordar, Las prioridades que indican el orden en el que se debe completar el trabajo y, La informacin, las funciones y los comportamientos que tendrn un impacto profundo en el diseo resultante. En resumen, la IR establece una base slida para el diseo y la construccin. Sin ella el software resultante tiene una alta probabilidad de NO SATISFACER las necesidades del cliente.
32
Tareas de la ingeniera de requisitos
La IR proporciona el mecanismo apropiado para entender lo que el cliente quiere, analizar necesidades, evaluar la factibilidad, negociar una solucin razonable, especificar la solucin sin ambigedades, validar la especificacin y administrar los requisitos conforme stos se transforman en un sistema operacional. Para poder llevar a cabo todo lo anterior se requieren de siete funciones o tareas: inicio, obtencin, elaboracin, negociacin, especificacin, validacin y gestin.
33
Tareas de la IR Inicio
Por lo general, la mayora de los proyectos comienza cuando se identifica una necesidad de negocios o se descubre un nuevo mercado o servicio potencial. En un escenario ideal, los clientes y los ingenieros de software trabajan juntos en el mismo equipo, en tal caso la IR se utiliza para guiar conversaciones significativas entre los miembros del equipo. Sin embargo la realidad a menudo es diferente. Los clientes pueden estar en una ciudad o pas diferente, puede que solo tengan una idea vaga de lo que se quiere, quiz su conocimiento tcnico sea limitado y tengan poco tiempo para interactuar con el ing. de requisitos, ninguna de estas situaciones es deseable pero, son muy comunes.
34
Pasos requeridos para iniciar la ingeniera de requisitos: Identificacin de los interesados. Los interesados son todos aquellos que se benefician de una forma directa e indirecta del sistema que est en desarrollo. Por ejemplo, gerentes, clientes internos y externos, usuarios finales, ingenieros de software, ingenieros de mantenimiento, etc. Cada interesado tiene una visin diferente del sistema, obtiene beneficios diferentes cuando ste se desarrolla de manera exitosa. En el inicio el ingeniero puede crear una lista de personas que contribuirn durante la obtencin de requisitos, sta puede crecer ya que a cada uno de ellos se les preguntar Con quin ms piensa que debera hablar?
35
Reconocimiento de mltiples puntos de vista. Debido a que existen muchos interesados diferentes, los requisitos del sistema se explotarn desde diversos puntos de vista. Por ejemplo, los gerentes estn interesados en que se satisfagan un conjunto de caractersticas sin rebasar un presupuesto, los usuarios finales desean caractersticas con las que estn familiarizados y sean fciles de aprender y utilizar, el ingeniero de mantenimiento se enfoca en la facilidad de mantenimiento del software, etc. Cada uno de ellos proporciona informacin al proceso de IR. Conforme se recopila esta informacin, los requisitos que surjan pueden ser inconsistentes. El trabajo del ingeniero de requisitos es categorizar toda la informacin de los interesados de tal forma que se pueda elegir un conjunto de requisitos para el sistema que sean consistentes de manera interna.
36
Trabajo con respecto a la colaboracin. Se ha mencionado que los clientes deben colaborar con los desarrolladores del software para lograr un producto exitoso. El trabajo del ingeniero de requisitos es identificar reas en comn (requisitos en los que todos estn de acuerdo) y reas de conflicto o inconsistencia (requisitos solicitados por un interesado entran en conflicto con las necesidades de otro). La colaboracin no significa, necesariamente, que los requisitos se definan por consenso. En muchos casos los interesados colaboran al proporcionar su visin de los requisitos, pero alguien importante (jerrquicamente) puede tomar la decisin final acerca de cules requisitos se aceptan.
37
Formulacin de las primeras preguntas. El primer conjunto de preguntas libre de contexto se enfoca en el cliente y otros interesados, metas generales y beneficios: Quines estn detrs de la solicitud de este trabajo? Quin usar la solucin? Cul ser el beneficio econmico de una solucin exitosa? Existe otra fuente para la solucin requerida? La siguiente serie de preguntas permiten que se comprenda mejor el problema y deja que el cliente exprese sus percepciones acerca de una solucin: Cmo podra caracterizarse un buen resultado generado por una solucin exitosa? Cules problemas debera atacar esta solucin? Podra usted describir o mostrar el ambiente de negocios que se utilizar en la solucin? Los aspectos especiales de desempeo o las restricciones afectarn la forma en que se busque la solucin?
38
La serie final de preguntas se enfoca en la efectividad de la actividad de comunicacin en si misma: Es usted la persona adecuada para contestar esta pregunta? sus respuestas son oficiales? Mis preguntas son relevantes para su problema? Estoy haciendo demasiadas preguntas? Alguien ms puede proporcionar informacin adicional? Debera preguntarle alguna otra cosa? El que pregunta es un tonto durante cinco minutos; el que no pregunta es un tonto por siempre (proverbio chino).
39
Tareas de la IR Obtencin de los requisitos

El formato de preguntas y respuestas propuesto en la tarea anterior (inicio) es til solo en la etapa inicial, de hecho se debe de usar para el primer encuentro y despus se debe reemplazar por un formato de obtencin de requisitos que combine elementos de la resolucin, elaboracin, negociacin y especificacin del problema. A continuacin describiremos un enfoque de este tipo.
40
Recopilacin conjunta de requisitos. Se han propuestos muchos enfoques para la recopilacin conjunta de requisitos. Cada uno utiliza un escenario diferente muy diferente. Pero todos aplican alguna variacin de las siguientes directrices bsicas: Las reuniones las dirige alguno de los asistentes, ya sea un ingeniero de software o un cliente. Se establecen reglas para la preparacin y la participacin. Se sugiere una agenda que sea tan formal como para cubrir todos los puntos importantes, pero tan informal como para estimular el flujo de ideas. Un moderador debe controlar la reunin. Se utiliza un mecanismo de definicin (hojas de trabajo, grficos, un tablero electrnico o un foro virtual). La meta es identificar el problema, proponer elementos de solucin, negociar diferentes enfoques y especificar un conjunto de requisitos de solucin preliminares en una atmsfera que 41 conduzca al cumplimiento de la meta.

Para entender mejor, se presenta un escenario que describe la secuencia de eventos que conducen a la reunin para la recopilacin de requisitos y que ocurren durante la reunin y despus de sta. Los participantes escriben una solicitud del producto en 1 o 2 pginas. Se fijan un lugar, una fecha y una hora para la reunin y se selecciona un moderador. Cada asistente debe hacer una lista de: Objetos que son parte del ambiente que rodea al sistema. Servicios (procesos o funciones) que manipulan o interactan con los objetos. Restricciones (costo, tamao, reglas de negocio) . Criterios de rendimiento (velocidad, exactitud). Se les informa que no se espera que las listas sean exhaustivas, sino 42 que reflejen la percepcin que cada persona tiene del sistema.

El primer tpico a tratar en la reunin es la necesidad y justificacin del nuevo producto. Despus, cada participante presenta sus listas para examinarlas. En una forma ideal, cada asunto en la lista debe permitir manipularse por separado para que las listas se puedan combinar, se le hagan eliminaciones o adiciones. El grupo crea listas combinadas para cada una de las reas de los distintos tpicos. El moderador coordina el debate. La lista combinada se reduce, se incrementa o replantea para reflejar de manera apropiada el producto/sistema que se desarrollar. El objetivo es desarrollar una lista consensada en el rea de cada tpico (objetos, servicios, restricciones y rendimiento). Despus dichas listas se integran para la accin posterior.
43
Despus cada equipo trabajar para desarrollar miniespecificaciones para uno o ms asuntos de cada una de las listas. Cada mini-especificacin es una explicacin concisa de la palabra o frase contenida en la lista. Por ejemplo la mini-especificacin para el objeto vehculo podra ser: El vehculo es una unidad motriz que la compaa adquiere para rentarla, dependiendo de su uso, tamao y otros detalles pueden pertenecer a un grupo y una clase, debe considerarse la disponibilidad del vehculo, ya que puede estar en preparacin, mantenimiento o reparacin. Despus cada equipo presenta sus mini-especificaciones a todos los asistentes para comentarlas. Se realizan las adiciones, anulaciones y elaboraciones posteriores. Se pueden descubrir nuevos requisitos de objetos, servicios restricciones y rendimiento que se agregarn a las listas originales.
44
Luego cada asistente hace una lista de criterios de validacin para el producto/sistema y la presenta a todos los miembros. Entonces se crea un lista consensada de criterios de validacin. Por ltimo, uno o ms participantes reciben el encargo de escribir las especificaciones completas mediante el uso de todos los asuntos tratados en la reunin.
45
Despliegue de la funcin de calidad. Es una tcnica que traduce las necesidades del cliente en requisitos tcnicos para el software. El QFD (qualified function deployment) se concentra en aumentar la satisfaccin del cliente desde el proceso de la IS. Para lograrlo, el QFD resalta una comprensin de lo que es valioso para el cliente y despus despliega estos valores durante el proceso de ingeniera. El QFD identifica tres tipos de requisitos: normales, esperados y, estimulantes46
Requisitos normales. Reflejan los objetivos y metas establecidas para un producto o sistema durante las reuniones con el cliente, por ejemplo las funciones especficas del sistema, los grficos en pantalla y los niveles de rendimiento solicitados. Requisitos esperados. Estn implcitos en el producto y son tan obvios que el cliente no los establece explcitamente, pero su ausencia causara una insatisfaccin significativa. Por ejemplo facilidad de interaccin, correccin, confiabilidad operacional, facilidad de instalacin. Requisitos estimulantes: Reflejan las caractersticas que van ms all de las expectativas del cliente. Por ejemplo, un procesador de palabras se solicita con caractersticas estndar y el producto entregado contiene capacidades de configuracin de pgina que son satisfactorias e inesperadas.
47
Escenarios del usuario

Conforme se recopilan los requisitos se comienza a materializar una visin ms general de las funciones y caractersticas del sistema. Para entender mejor la forma en que se aplicarn estas funciones y caractersticas los desarrolladores y usuarios pueden crear un conjunto de escenarios que identifiquen una cadena de uso para el sistema que se va a construir. Los escenarios (casos de uso) describen como se usar el sistema.
48
Productos de trabajo de la Obtencin

Los productos que se obtienen aqu varan de acuerdo al tamao del sistema, pero la mayora incluye los siguientes: Un enunciado de necesidad y factibilidad. Un enunciado limitado del mbito del sistema. Una lista de clientes, usuarios y otros interesados que participaron en la obtencin de requisitos. Una descripcin del ambiente tcnico del sistema. Una lista de requisitos (ordenados por funcin) y las restricciones de dominio aplicables a cada uno. Un conjunto de escenarios de uso que representa la utilizacin del sistema. Prototipos desarrollados para definir de mejor forma los requisitos.
49
Desarrollo de casos de uso

Segn Cockburn, un caso de uso describe el comportamiento del sistema en diferentes condiciones mientras ste responde a las peticiones de uno de sus usuarios. En esencia, un caso de uso cuenta una historia estilizada de la manera en que un usuario final interacta con el sistema en un conjunto especfico de circunstancias. Sin importar su forma, un caso de uso muestra el sistema desde el punto de vista del usuario final.
50

El primer paso al escribir un caso de uso consiste en definir el conjunto de actores que estarn involucrados en la historia. Los actores puede ser alguien o algo que se comunica con el sistema y que es externo al sistema en s mismo. Cada actor tiene una o ms metas cuando utiliza el sistema. La obtencin de requisitos es una actividad evolutiva, por lo que no todos los actores podrn ser identificados en la primera iteracin. Hay dos tipos de actores: Primarios: interactan para lograr la funcin requerida del sistema y obtienen el beneficio que se espera de ste. Secundarios: dan soporte al sistema de manera que los actores primarios puedan hacer su trabajo.
51

Una vez identificados los actores, se pueden desarrollar los casos de uso. Jacobson sugiere varias preguntas que deben contestarse mediante un caso de uso. Quin es el actor primario (o quienes)? Cules son las metas del actor? Cules son las condiciones que deben existir antes de comenzar la historia? Cules son las tareas o funciones principales que realiza el actor? Cules excepciones podran considerarse mientras se describe la historia? Cules son las variaciones posibles en la interaccin del actor? Cul es la informacin del sistema que el actor adquirir, producir o cambiar? Cul es la informacin que el actor desea del sistema?
52
Desarrollo de casos de uso: un ejemplo
Proceso de venta: llega un cliente al mostrador con los artculos que quiere comprar. El cajero usa el sistema POS para registrar cada artculo vendido. El sistema presenta el total de la venta y los artculos detallados lnea por lnea. El cliente incorpora la informacin del pago, la cual es validada y registrada por el sistema. El sistema actualiza el inventario. El cliente recibe una factura del sistema y luego se va con sus artculos.
53
Los casos de uso deben ser mas elaborados que el ejemplo, pero la esencia es descubrir y registrar los requerimientos funcionales escribiendo historias del uso del sistema para ayudar a satisfacer las metas de los involucrados en el sistema.
54
Desarrollo de casos de uso: algunas definiciones
Actor: es algo con comportamiento, tal como una persona (identificada por un rol), sistema u organizacin, por ejemplo un cajero. Escenario: una secuencia especifica de acciones e interaciones entre actores y el sistema bajo discusin, a esto tambin se le llama una instancia del caso de uso. Un caso de uso es una coleccin de escenarios exitosos y fallidos que describen a los actores usando un sistema para lograr una meta.
55
Caso de uso UC1: Proceso de venta

Actor principal: cajero Interesados: cajero: quiere exactitud, entrada rpida y no pagar errores. Vendedor: quiere las comisiones de las ventas actualizadas. Cliente: quiere compras y servicios rpidos con mnimo esfuerzo. Quiere prueba de compra para poder regresar. Compaa: .. Precondiciones: que el cajero se identifique. Garanta de xito (Poscondiciones): la venta es almacenada. El impuesto es calculado correctamente. Contabilidad e inventarios se actualizan, se registran las comisiones, se genera el recibo y la autorizacin del pago es aprobado y registrado.
56

Escenario exitoso principal (flujo bsico): 1. Llega el cliente a la caja con artculos y/o servicios para comprar 2. El cajero inicia una nueva venta 3. El cajero introduce el cdigo del art. . Extensiones (flujo alternativo) 3a. Cdigo invalido 3-6b. El cliente le dice al cajerto que cancele la venta ..
57

Requerimientos especiales: La respuesta de autorizacin de crdito debe ser de 30 segundos mximo. Una touch screeen. El texto debe ser visible a 1 metro. Tecnologa 1. El identificador de los artculos se lee por medio de un lector de cdigos de barra o por el teclado. 2. La firma de los pagos de crdito se captura en el recibo de papel. Pero dentro de 2 aos se predice que muchos clientes querrn una captura digital de su firma.
58

Frecuencia de ocurrencia: (lo que podra continuar cercanamente) - Explorar el servicio remoto de recuperacin. - Qu adecuaciones son necesarias para los diferentes tipos de negocios? - Puede el cliente usar directamente el lector de tarjeta o debe hacerlo el cajero? - .
59
Diagrama de casos de uso

Proceso de vta Manejo de dev.
Cajero
Entrada de dinero
Servicio de autorizacin de pagos

<<actor>> Calculador de impuestos <<actor>> Sistema contable
<<actor>> Sistema de actividad de ventas
Analizar actividad
Manejo de seguridad Manejo de usuarios
Administrador
60
Tip para escribir casos de uso exitosos
La actitud clave en el trabajo de casos de uso es enfocarse en la pregunta: Cmo puedo usar el sistema para proporcionar un valor observable al usuario o satisfacer sus metas? En lugar de pensar nicamente de los requerimientos del sistema en trminos de una lista de caractersticas o funciones. En www.usecases.org pueden encontrar una gran variedad de plantillas para desarrollar casos de uso, as como una base de datos para soportarlos.
61
Construccin del modelo de anlisis

El objetivo del modelo de anlisis es describir los dominios requeridos de informacin, funcionamiento y comportamiento para un sistema basado en computadoras. El modelo cambia en forma dinmica conforme los desarrolladores aprenden ms acerca del sistema que se va a construir y los interesados entienden mejor lo que necesitan. En la siguiente unidad veremos con ms detalle diferentes formas de construir el modelo de anlisis, por lo pronto, presentar una breve visin general.
62
Elementos del modelo de anlisis

Existen muchas maneras de buscar requisitos para un sistema: Se pude seleccionar un modo de representacin (casos de uso). Puede ser valioso utilizar varios modos de representacin, pues esto obliga al equipo de desarrollo a considerar los requisitos desde diferentes puntos de vista. Los elementos especficos del modelo de anlisis los determina el MTODO de modelado que se utilice. Sin embargo, existe un conjunto de elementos genricos comn a la mayora de los modelos de anlisis.
63
Elementos basados en escenarios

El sistema se describe desde el punto de vista del usuario, por medio de un enfoque basado en escenarios. Por ejemplo, los casos de uso bsicos y sus correspondientes diagramas de casos de uso evolucionan para convertirse en casos de uso ms elaborados basados en plantillas. Un enfoque diferente dentro del modelado basado en escenarios muestras las actividades o funciones que han sido definidas como parte de la tarea de obtencin de requisitos. Estas funciones (operaciones) se representan como una secuencia de actividades que describe el procesamiento dentro de un contexto limitado
64
Realizar reuniones Listas de funciones y clases

Listas de restricciones etc.
Obtener requisitos
priorizacin formal? si
Definir actores Escribir el escenario Escribir el escenario

Crear casos de uso
no
Utilizar QFD Para jerarquizar requisitos
Jerarquizar informal
Diagrama de actividades para la obtencin de requisitos
Completar la plantilla
65
Elementos basados en clases

Cada escenario de uso implica un conjunto de objetos que se manipulan mientras un actor interacta con el sistema. Estos objetos se clasifican en clases: una coleccin de objetos con atributos similares y comportamiento en comn. Se puede usar el diagrama de clases para mostrar las clases de un dominio dado. Adems en el diagrama de clases se puede mostrar la relaciones e interacciones entre las clases, otros elementos podran mostrar el cmo colaboran los objetos o clases entre si (diagramas de secuencia del sistema).
66
Diagrama de clases (parcial)
Venta
fecha hora getTotal()
Especificacion DelProducto
Descripcion precio articuloID getPrecio()
67
Elementos de comportamiento
El comportamiento de un sistema basado en computadora puede tener un profundo efecto sobre el diseo que se elija, as como en el enfoque de implementacin que se aplique. Por lo que el modelo de anlisis debe proporcionar elementos de modelado que muestren el comportamiento. El diagrama de estado es un mtodo para representar el comportamiento de un sistema al mostrar sus estados y los eventos que ocasionan que dicho sistema cambie de estado. Un estado es cualquier forma de comportamiento observable. Adems, el diagrama de estado indica las acciones que se toman como consecuencia de un evento particular.
68
Unidad III
Modelado de Anlisis
69
Introduccin
El modelo de anlisis, que en realidad es una serie de modelos, es la primera representacin tcnica de un sistema. DeMarco en su libro sobre mtodos de anlisis define el proceso de la siguiente manera: Al observar los problemas y fallas reconocidas de la fase de anlisis es necesario agregar los siguientes objetivos: Los productos de anlisis deben tener una elevada facilidad de mantenimiento. Esto se aplica en particular al documento final (especificacin de requisitos). Los problemas de gran tamao deben tratarse con un mtodo efectivo de particin. Deben utilizarse grficas cuando sea posible. Se debe diferenciar entre consideraciones lgicas (esenciales) y fsicas (de implementacin).
70
Introduccin
Como mnimo se necesita: Algo que ayude a hacer una particin de los requisitos y a documentarlos antes de la especificacin. Algunos medios para el seguimiento y evaluacin de las interfases Herramientas nuevas para describir la lgica y la tctica, algo mejor que un texto narrativo. Aunque DeMarco escribi sobre esto hace ms de un cuarto de siglo, sus contribuciones se siguen aplicando en la notacin y los mtodos modernos de modelado del anlisis.
71
Anlisis de requisitos
El anlisis de requisitos genera la especificacin de caractersticas operacionales del software; indica la interfaz del software con otros elementos del sistema, y establece las restricciones que debe tener el software. El anlisis de requisitos le proporciona al diseador del software una representacin de informacin, funcin y comportamiento que puede trasladar a diseos arquitectnicos, de interfaz y en el nivel de componentes. Adems el modelo de anlisis y la especificacin de requisitos proporcionan al desarrollador y a l cliente los mtodos para evaluar la calidad una vez construido el software.
72
Anlisis de requisitos
Durante el modelado de anlisis el ingeniero de software se centra en el QU y no en el cmo. Qu objetos manipula el sistema? Qu funciones debe desempear el sistema? Qu comportamientos muestra el sistema? Qu interfaces se definen? Qu restricciones se aplican?
73
Objetivos del modelo de anlisis

El modelo de anlisis debe cumplir con 3 objetivos primarios: 1. Describir lo que requiere el cliente 2. Establecer una base para la creacin de un diseo de software 3. Definir un conjunto de requisitos que puedn validarse una vez construido el software.
74
Enfoques del modelado del anlisis
Una visin del modelado de anlisis llamado anlisis estructurado, considera que los datos y el proceso que transforma los datos son entidades separadas. Los objetos de datos1 se modelan en una forma que definen sus atributos y relaciones. Los procesos que manipulan los objetos de datos se modelan de tal maneta que muestran cmo transforman los datos, mientras los objetos de datos fluyen por el sistema.
1 Un objeto de datos es una representacin de cualquier informacin compuesta que se procesa en software 75
Enfoques del modelado del anlisis
Un segundo enfoque de modelado del anlisis, llamado anlisis orientado a objetos, se centra en la definicin de clases y objetos y la manera en que stos colaboran entre si para satisfacer los requisitos del sistema.
76
Conceptos del modelado de datos (objetos de datos)

El modelado de anlisis a menudo comienza con el modelado de los datos. El ingeniero de software define todos los objetos de datos que se procesan dentro del sistema y las relaciones entre los objetos de datos. Objeto de datos: es una representacin de cualquier informacin compuesta que el software debe entender. Informacin compuesta: se refiere a algo que tiene muchas propiedades o atributos diferentes, por ejemplo: anchura: es un valor individual, no sera un objeto de datos vlido dimensiones: la incorporacin de anchura, altura y profundidad podran definirse como un objeto de datos.
77

Una persona o un auto pueden verse como un objeto de datos en el sentido de que cualquiera de ellos puede definirse en trminos de un conjunto de atributos. La descripcin del objeto de datos incorpora el objeto y todos sus atributos. Un objeto de datos encapsula slo datos: no existe alguna referencia a las operaciones que actan sobre los datos. Por lo tanto, el objeto de datos puede representarse como una tabla. Los encabezados de la tabla reflejan los atributos del objetos, el contenido de la tabla representa ejemplo especficos del objeto de datos.
78
REPRESENTACIN TABULAR DE OBJETOS DE DATOS
identificador
Marca Lexus Chevrolet BMW TOYOTA Modelo LS400 CORVETTE 750iL CAMRY Id AB123 X456 XZ765 Q12A45
Atributos descriptivos
Tipo SEDAN DEPORTIVO COUPE XLE Color BLANCO ROJO PLATA GRIS
Atributos referenciales
Propietario RSP CCD UL BLF
Los atributos definen las propiedades de un objeto de datos y toman una de tres caractersticas diferentes:
1.
2. 3.
Nombrar una ocurrencia del objeto de datos.

Describir la ocurrencia Hacer referencia a otra ocurrencia en otra tabla.
Adems se debe definir uno o ms atributos como identificador, el cual se convierte en una clave cuando se desea encontrar una ocurrencia del objeto de datos. 79
Relaciones. Los objetos de datos estn conectados entre s de muchas maneras diferentes. Pero, Cmo encontramos esas relaciones? Las relaciones se determinan o definen entendiendo el papel o rol que juegan los objetos de datos dentro del contexto del software que se construir. Se puede definir un conjunto de parejas objeto/relacin que definan las relaciones relevantes:

Una persona posee un auto. Una persona est asegurada para conducir un auto.
Las relaciones posee y est asegurada para conducir definen las conexiones relevantes entre persona y auto. La siguiente figura lo ilustra.
80

a) Una conexin bsica entre objetos de datos
persona automvil
posee
b) Relaciones entre objetos de datos persona Asegurada para manejar automvil
81

Cardinalidad y modalidad. Los elementos del modelado de datos (objetos de datos, atributos y relaciones) ofrecen la base para entender el dominio de informacin de un problema. Sin embargo, tambin es necesario comprender informacin adicional relacionada con estos elementos bsicos. Se debe definir cuntas ocurrencias del objetoX estn relacionadas con cuntas ocurrencias del objetoY, esto nos conduce al concepto de modelado datos llamado cardinalidad. La cardinalidad segn Tillmann es: la especificacin del nmero de ocurrencias de un objeto que puede relacionarse con el nmero de ocurrencias de otro objeto. Por ejemplo relaciones 1:1, 1:N o M:N. La cardinalidad tambin define el nmero mximo de objetos que pueden participar en una relacin.
82

La modalidad sirve para indicar si un objeto particular de datos debe participar o no en la relacin. La modalidad de una relacin es de 0 si no hay una necesidad explcita para que ocurra la relacin o la relacin es opcional. La modalidad es 1 si una ocurrencia de la relacin es obligatoria.
Para que un sistema de informacin sea til, confiable, adaptable y econmico debe estar basado primero en el modelado de datos, y slo de manera secundaria en el anlisis del proceso porque la estructura de datos se refiere de forma inherente a la verdad, mientras que el proceso es relativo a la tcnica. Duncan Dwelle.
83
Modelado basado en escenarios

Aunque el xito de un sistema basado en computadora se mide en muchas formas, la satisfaccin del cliente es la principal. En la medida en que los ingenieros de software entiendan la manera en que los usuarios finales (y otros actores) quieren interactuar con el sistema, sern ms capaces de caracterizar en forma apropiada los requisitos y construir modelos significativos de anlisis y diseo. Por lo que el modelado de anlisis con UML comienza con la creacin de escenarios en la forma de casos de uso, diagramas de actividad y diagramas de carril.
84

(escritura de casos de uso)
El concepto de caso de uso es relativamente fcil de entender: describe un escenario de uso especfico en un lenguaje directo desde el punto de vista de un actor definido. Para que los casos de uso tengan un valor como herramienta para el modelado de anlisis deben contestarse las siguientes preguntas: Sobre qu escribir? Cunto escribir acerca de ello? Qu tan detallada debe ser la descripcin? Cmo organizar la descripcin?
85

(escritura de casos de uso)
Las primeras dos tareas de la ingeniera de requisitos (inicio y obtencin) proporcionan la informacin necesaria para comenzar a escribir los casos de uso, ya que mediante esas tareas se identificaron a los interesados, se defini el mbito del problema, se especificaron las metas operativas globales, se identificaron los requisitos funcionales y se describieron los objetos que manipular el sistema.
86
Un ejemplo
La funcin de vigilancia en el hogar de hogar seguro identifica las siguientes funciones (lista abreviada) que realiza el actor identificado como propietario de la casa: Tener acceso a la cmara de vigilancia va internet. Seleccionar la cmara que desea ver. Solicitar vistas en miniatura de todas las cmaras. Desplegar vistas de la cmara en una ventana de una PC. Controlar la visin panormica y de acercamiento en una cmara especfica. Registrar en forma selectiva la salida de cmara. Repetir la salida de cmara. El equipo de recopilacin de requisitos desarrolla casos de uso para cada una de las funciones mencionadas. Se pueden describir en un estilo narrativo informal o se puede 87 utilizar un formato estructurado (como el que ya vimos).
Un ejemplo (narrativo informal)

Caso de uso: Acceso a la cmara de vigilancia despliegue de vistas de cmara (ACV DVC). Actor: Propietario. Si me encuentro en un lugar lejano, puedo usar una PC con un software de navegacin apropiado para entrar al sitio WEB de los productos Hogar Seguro. Ingreso mi clave de usuario y dos niveles de contrasea y, despus de que estoy validado tengo acceso a toda la funcionalidad de mi sistema HogarSeguro instalado. Para tener acceso a la vista de una cmara especfica selecciono vigilancia de los botones desplegados para las funciones ms importantes. Despus escojo seleccionar una cmara y se despliega un plano de planta de la casa. Entonces selecciono la cmara en la que estoy interesado. En forma alterna puedo ver una simultneamente una lista con vistas en miniatura de todas las cmaras a l seleccionar todas las cmaras como mi opcin de visualizacin. Una vez que he seleccionado una cmara, selecciono vista y una vista de un cuadro por segundo aparece en una ventana, a la cual identifica la cmara clave. Si quiero cambiar de cmara elijo seleccionar una cmara y la ventana de visin original desaparece y se despliega de nuevo el plano de planta de la casa. 88
Un ejemplo (secuencia ordenada de acciones)

Caso de uso: Acceso a la cmara de vigilancia despliegue de vistas de cmara (ACV DVC). Actor: Propietario. 1. El propietario entra en el sitio WEB de HogarSeguro. 2. El propietario introduce su clave de usuario. 3. El propietario introduce las contraseas (c/u de al menos 8 caracteres). 4. El sistema despliega todos los botones de las funciones ms importantes. 5. El propietario selecciona vigilancia. 6. El propietario elije seleccionar una cmara 7. El sistema despliega el plano de planta de la casa. 8. El propietario selecciona un cono de cmara del plano de planta. 9. El propietario selecciona el botn vista. 10. El sistema despliega una ventana de visin, identificado por la clave de la cmara. 11. El sistema muestra salida de video dentro de la venta de visin con una velocidad de un marco por segundo. 89
Diagramas de casos de uso
La representacin diagramtica puede facilitar la comprensin de un escenario de uso, en particular cuando este es complejo. UML proporciona una capacidad para hacer diagramas de casos de uso. Cada caso de uso se representa mediante un valo.
90
Diagrama preliminar de casos de uso para el sistema HogarSeguro

Hogar Seguro Acceso a la cmara de vigilancia va internet
Cmaras
Propietario de la casa
Configurara sistema
Configurar alarma
91
Desarrollo de un diagrama de actividad

El diagrama de actividad en UML complementa el caso de uso al proporcionar una representacin grfica del flujo de interaccin de un escenario especfico. Notacin:
Los rectngulos con esquinas redondeadas representan funciones. Las flechas representan el flujo a travs del sistema. Los rombos representan decisiones Lneas horizontales slidas para indicar que ocurren actividades paralelas.
92
Diagrama de actividades para la funcin de acceso a la cmara de vigilanciadespliegue de vistas de cmara
Introducir contrasea e ID de usuario
Contraseas/ID vlidas
Selecciona una Funcin importante
Contraseas/ID no vlidas Opcin para reingreso

Restan intentos
Seleccionar vigilancia Seleccionar una
Vistas en miniatura
Selecciona una Cmara especifica
cmara especifica
Selecciona un icono de cmara
No restan intentos
Ver la salida de una cmara en una ventana etiquetada Opcin para otra vista
Salir de esta funcin
Ver otra cmara
93
Modelado orientado al flujo

El modelo de datos orientado al flujo es una de las notaciones de anlisis ms utilizadas. El diagrama de flujo de datos (DFD) tiene una visin del sistema del tipo entrada-proceso-salida. Esto significa que los objetos de datos fluyen hacia el interior del software se transforman mediante elementos de procesamiento, y los objetos de datos resultantes fluyen al exterior del software. Los objetos de datos se representan mediante flechas rotuladas y las transformaciones se representan mediante crculos (burbujas).
94
Modelado orientado al flujo

El DFD se representa en forma jerrquica, esto es, el primer modelo de flujo de datos (DFD de nivel 0 o diagrama de contexto) representa el sistema como un todo. Los DFD subsecuentes refinan el diagrama de contexto, ya que proporcionan una cantidad creciente de detalles con cada nivel subsecuente.
95
Creacin de un modelo de flujo de datos

El DFD permite que el ingeniero de software desarrolle modelos del dominio de informacin y del dominio funcional al mismo tiempo. A medida que el DFD se refina hacia grados mayores de detalle, el ingeniero desempea una descomposicin funcional implcita del sistema. Al mismo tiempo, el refinamiento del DFD resulta en un correspondiente refinamiento de datos mientras estos se mueven hacia los procesos que incorpora la aplicacin.
96
Creacin de un modelo de flujo de datos

Directrices para la creacin de un DFD: 1. El nivel 0 del DFD debe representar el software/sistema como una sola burbuja. 2. La entrada y salida primaria deben establecerse con cuidado. 3. El refinamiento debe comenzar por el aislamiento de procesos, objetos de datos y almacenamiento de datos candidatos a ser representados en el siguiente nivel. 4. Todas las flechas y burbujas deben rotularse con nombres significativos. 5. Se debe mantener la continuidad del flujo de informacin al cambiar de nivel a nivel. 6. El refinamiento de las burbujas se debe hacer de una por una.
97
Panel de
Control
comandos y datos del usuario
Despliegue de informacin
Software de HogarSeguro
Despliegue del panel de control
Tipo de alarma
Alarma
Estatus del sensor Sensores Tonos del nmero telefnico Lnea Telefnica
DFD de nivel contextual para HogarSeguro

98
DFD DE NIVEL 0 PARA HOGAR SEGURO

En el diagrama anterior las entidades externas primarias (cajas) producen informacin para el uso del sistema y consumen informacin que ste genera. Las flechas rotuladas representan objetos de datos o jerarquas de objetos de datos. Por ejemplo: comandos y datos de usuario abarcan todos los comandos de configuracin, todos los comandos de activacin/desactivacin, todas las interacciones y todos los datos que se ingresan para calificar o expandir un comando.
99
Refinando el DFD de nivel 0

El DFD de nivel 0 debe expandirse a un modelo de flujo de nivel 1. Cmo se logra esto? Realizando un anlisis gramatical sobre la narrativa que describe la burbuja a nivel de contexto. El anlisis gramatical consiste en aislar todos los sustantivos y verbos en la narrativa de procesamiento de HograSeguro .
100
Anlisis gramatical
El anlisis gramatical descubrimos un patrn: los verbos son los procesos, es decir, pueden representarse como burbujas en un DFD subsecuente, los sustantivos son entidades externas (cajas), objetos de datos o de control (flechas), o almacenamientos de datos (lneas dobles). Los sustantivos y verbos se pueden asociar. Por ejemplo, a cada sensor se le asigna un nmero y un tipo, por lo que el numero y el tipo son atributos del objeto de datos sensor. Por lo que el hacer el anlisis gramatical sobre la narrativa de procesamiento para una burbuja de cualquier nivel de DFD genera mucha informacin til para proceder con los DFD de siguiente nivel.
101
Panel de control
Comandos y datos de usuario
Configurar sistema
Datos de Configuracin Informacin de Configuracin
Subsistema de interaccin con el usuario
Interactuar con el usuario
Peticin de Configuracin
Iniciar/detener
Contrasea
Activar/ desactivar sistema

Mensaje de A/D
Datos de Configuracin
Monitor de Panel de Control
Procesar contrase Mensaje de ID vlido a Datos de Configuracin Monitorear sensores
Desplegar mensajes y estatus
Desplegar informacin
Informacin del sensor Tipo de alarma Tonos del nmero telefnico
Alarma
Lnea Telefnica
102
Sensores
Estatus del Sensor
DFD de nivel 1 para HogarSeguro
Hasta cuando dejar de refinar
Los procesos representados en el DFD de nivel 1 se refinan despus hacia niveles ms bajos. El refinamiento de los DFD contina hasta que cada burbuja realiza una sola funcin, es decir, hasta que el proceso que representa la burbuja desempee una funcin que pueda implementarse con facilidad como un componente de programa.
103
Especificacin del proceso
La especificacin del proceso (EP) se utiliza para describir todos los procesos del modelo de flujo que aparecen en el nivel final de refinamiento. El contenido de la especificacin de proceso puede incluir texto narrativo, una descripcin el lenguaje de diseo de programas (LDP) del algoritmo del proceso, ecuaciones matemticas, tablas, diagramas o grficas. Al proporcionar una EP para acompaar cada burbuja en el modelo de flujo se crea una mini-especificacin que sirve como gua para el diseo del componente de software que implementar el proceso.
104
Informacin de Configuracin
Formato para el despliegue Id, tipo, ubicacin de sensor
Subsistema de monitoreo de Informacin sensores del sensor
Datos de configuracin
Evaluar contra configuracin
Datos de alarma
Generar seal de alarma
Tipo de alarma
Leer sensores Estatus del Sensor
Id, tipo de sensor
Nmero telefnico
Marcar telfono
Sensores
Tonos de nmeros telefnicos
105
DFD de nivel 1 para HogarSeguro
Modelado basado en clases

Al mirar al interior de una habitacin se ver que existe un conjunto de objetos fsicos que pueden identificarse, clasificarse y definirse con facilidad (atributos y operaciones). Pero cuando se observa el espacio del problema de una aplicacin de software quizs las clases y los objetos sean ms difciles de comprender. Se puede iniciar la identificacin de clases al examinar el enunciado del problema, haciendo un anlisis gramatical sobre las narrativas o sobre los casos de uso. Las clases se determinan al localizar cada sustantivo, los sinnimos deben anotarse.
106

Las clases se manifiestan en una de las siguientes formas: Entidades externas, por ejemplo personas, dispositivo, otros sistemas que producen o consumen informacin que usar el sistema Cosas, como reportes, despliegues, letras o seales que son parte del dominio de informacin del problema. Sucesos o eventos que ocurren dentro del contexto de la operacin de un sistema. Papeles que desempean personas que interactan con el sistema (p.ej.: gerente, ingeniero, personal de venta, cajero, etc.). Unidades organizacionales relevantes para alguna aplicacin, por ejemplo divisin, grupo, equipo, etc. Sitios, por ejemplo el puerto de carga, el rea de manufactura, etc. Que establecen el contexto del problema y la funcin global del sistema Estructuras que definen una clase de objetos o clases de objetos relacionados, por ejemplo: sensores, vehculos de cuatro ruedas, computadoras, etc. Esta categorizacin es una de las muchas que se han propuesto en la 107 bibliografa.

Para ilustrar la forma en que pueden definirse las clases de anlisis, tomaremos de nuevo la funcin de seguridad de HogarSeguro, y se proponen un conjunto de clases potenciales:
108
Clase potencial
Propietario
Sensor Panel de control Instalacin Sistema Contrasea maestra Nmero telefnico Evento del sensor Alarma audible Servicio de monitoreo Nmero, tipo
clasificacin
Papel o entidad externa
Entidad externa Entidad externa Ocurrencia Cosa Cosa Cosa Ocurrencia Entidad externa Unidad organizacional Atributos de sensor
La lista podra extenderse hasta que todos los sustantivos de la narrativa de procesamiento hayan sido considerados 109

Para considerar incluir las clases potenciales en el modelo de anlisis se sugieren 6 caractersticas de seleccin propuestas por Coad y Yourdon: 1. Informacin referida. Si la informacin acerca de la clase debe recordarse para que el sistema pueda funcionar. 2. Servicios requeridos. La clase debe tener un conjunto de operaciones que puedan cambiar el valor de sus atributos. 3. Atributos mltiples. La clase debe tener ms de un atributo, si no es as, entonces es conveniente presentarla como atributo de otra clase. 4. Atributos comunes. Debe ser posible definir un conjunto de atributos para la clase y estos se deben poder aplicar a todas las instancias de la clase. 5. Operaciones comunes. Debe ser posible definir un conjunto de operaciones para la clase y estas deben poder aplicarse a todas las instancias de la clase. 6. Requisitos esenciales. Las entidades externas que producen o consumen informacin esencial para la operacin del sistema se definirn casi siempre como clases en el modelo de requisitos. Para incluir una clase en el modelo de anlisis, esta debe satisfacer todas (o casi todas) estas caractersticas.
110
Modelado basado en clases, especificacin de atributos.

En esencia los atributos son los que definen la clase, lo cual clarifica qu significa la clase en el contexto del espacio del problema. Para obtener un conjunto significativo de atributos para una clase de anlisis se recomienda estudiar los casos de uso y seleccionar aquellas cosas que pertenecen de manera razonable a la clase.
111
Modelado basado en clases, especificacin de atributos.

Un atributo es un valor de datos lgico de un objeto. En un modelo de dominio se deben incluir los siguientes atributos: Aquellos para los que los requisitos (casos de uso) sugieren o implican una necesidad de registrar la informacin.
112
Notacin UML de los atributos

Venta
fecha horainicio:Hora
113
Tipos de atributos vlidos

Los atributos en un modelo de dominio deben de ser, preferentemente atributos simples o tipos de datos. Los tipos de datos de los atributos muy comunes incluyen: Boolean, Fecha, Numero, String (texto), Hora. Otros tipos comunes comprenden: Direccin, Color, No. de telfono, No. De la seguridad social, Cdigo de Precio Universal (UPC), cdigos postales, tipos enumerados.
114
Relacionar las clases conceptuales con una asociacin no con un atributo.
Vuelo
destino
Peor
Destino es un concepto complejo
Vuelo
Vuela-a
Aeropuerto
Mejor
115
Atributos en el modelo del dominio del sistema Punto de Venta

Pago. Cantidad: se debe capturar una cantidad para determinar si se proporciona el pago suficiente y calcular el cambio. EspecificacionDelProducto. Descripcion: para mostrar la descripcin en una pantalla o recibo. ID: para buscar una EspecificacionDelProducto dado un articuloID introducido, es necesario relacionarlas con un ID. Precio: para calcular el total de la venta y mostrar el precio de lnea de venta. Venta. Fecha, hora: un recibo es un informe en papel de una venta. Normalmente muestra la fecha y la hora de la venta. LineaDeVenta. Cantidad: para registrar la cantidad introducida, cuando hay ms de un artculo en una lnea de venta. Tienda. Direccion, nombre: el recibo requiere el nombre y la direccin de la tienda.
116
Definicin de operaciones
Las operaciones definen el comportamiento de un objeto. Como una primera iteracin en la obtencin de un conjunto de operaciones para una clase de anlisis, se deben estudiar los casos de uso y seleccionar aquellas operaciones que pertenezcan de manera razonable a la clase (identificar verbos).
117
Operaciones
Una operacin denota un servicio que una clase ofrece a sus clientes. En la prctica se ha visto que un cliente realiza tpicamente 5 tipos de operaciones sobre un objeto. Los 3 tipos ms comunes son:
Modificador. Una operacin que altera el estado de un objeto. Selector. Una operacin que accede al estado de un objeto, pero no altera ese estado. Iterador. Una operacin que permite acceder a todas las partes de un objeto en algn orden perfectamente bien establecido.
118
Operaciones
Los otros dos tipos de operaciones habituales representan la infraestructura necesaria para crear y destruir instancias de una clase:
Constructor. Una operacin que crea un objeto y/o inicializa su estado. Destructor. Una operacin que libera el estado de un objeto y/o destruye el propio objeto.
119
Relaciones entre clases
Consideremos por un momento las analogas y diferencias de las siguientes clases de objetos:
Flores Margaritas Rosas rojas Rosas amarillas Ptalos Mariquitas Podemos hacer las siguientes observaciones:
120

Una margarita es un tipo de flor. Una rosa es un tipo (distinto) de flor Las rosas rojas y las rosas amarillas son tipos de rosas. Un ptalo es una parte de ambos tipos de flores. Las mariquitas se comen a ciertas plagas como los pulgones, que pueden infectar ciertos tipos de flores.
121
Partiendo de este ejemplo se concluye que las clases, al igual que los objetos, no existen aisladamente. Para un dominio de problema especfico, las abstracciones claves suelen estar relacionadas por vas muy diversas e interesantes, formando la estructura de clases del diseo.
122
Se establecen relaciones entre dos clases por una de dos razones:
Primero: una relacin entre clases podra indicar algn tipo de comparticin. Por ejemplo las rosas y las margaritas son tipos de flores, por lo que ambas tienen ptalos, emiten una fragancia, etc. Segundo: una relacin entre clases podra indicar algn tipo de conexin semntica. Por ejemplo las mariquitas protegen a las flores de las plagas y a su vez esto sirve de alimento a las mariquitas
123
Tipos de relaciones
En total existen 3 tipos bsicos de relaciones entre clases: Generalizacin/especializacin (herencia). Que denota una relacin es un, por ejemplo una rosa es un tipo de flor, lo que quiere decir que una rosa es una subclase especializada de una clase ms general, la de las flores. Todo/parte (agregacin). Que denota una relacin parte de, por ejemplo ptalo es una parte de una flor. Asociacin. Que denota alguna dependencia semntica entre clases. Por ejemplo las mariquitas y las flores, otro ejemplo ms: las rosas y las velas, son clases claramente independientes pero ambas representan cosas que se utilizan para adornar una mesa.
124
Tipos de relaciones
En los lenguajes de programacin han evolucionado varios enfoques comunes para plasmar estos tres tipos de relaciones. La mayora de los lenguajes OO ofrecen soporte directo para alguna combinacin de las siguientes relaciones: Asociacin Herencia Agregacin Uso
125
Relacin de Asociacin
Asociacin: es el tipo de relacin ms general, pero el de mayor debilidad semntica. La identificacin de asociaciones entre clases es frecuentemente una actividad de anlisis y de diseo inicial . A medida que se contina en el diseo y la implementacin, se refinan estas asociaciones dbiles convirtindolas en otras relaciones de clases ms concretas.
126
Asociacin
Ejemplo: En un sistema automatizado para punto de venta, dos de las abstracciones clave incluyen productos y ventas. Se puede establecer una asociacin simple entre estas dos clases: la clase Producto denota los productos que se venden como parte de una venta, y la clase Venta denota la transaccin por la cual varios productos acaban de venderse. Esta asociacin sugiere una relacin bidireccional: dada una instancia de Producto, deberamos ser capaces de encontrar el objeto que denota su venta y, dada una instancia de Venta, deberamos ser capaces de localizar todos los productos vendidos en esa transaccin.
127
Producto
Venta 1..* 1
Esto se puede representar en C++, consideremos la declaracin muy resumida de estas dos clases:
class Producto; class Venta; class Producto { public: .. protected: Venta * ultimaVenta; };
class Venta { public: .. protected: Producto ** productoVendido; };
Aqu se muestra una asociacin uno-a-muchos: cada instancia de Producto puede tener un apuntador a su ltima venta, y cada instancia de Venta puede tener una 128 coleccin de apuntadores que denota los productos vendidos en esa venta.
Dependencia semntica
Como sugiere este ejemplo, una asociacin solo denota una dependencia semntica y no establece la direccin de esta dependencia, ni establece la forma exacta en que una clase se relaciona con otra. Sin embargo esta semntica es suficiente durante el anlisis del problema, momento en el cual solo es necesario identificar esas dependencias. Mediante la asociacin se establece quienes son los participantes en una relacin semntica, sus papeles y su cardinalidad (multiplicidad).
129
Herencia
La herencia es la relacin ms interesante, semnticamente hablando, existe para expresar relaciones de generalizacin/especializacin. Siguiendo con el ejemplo de punto de venta, consideremos que las ventas se pagan en efectivo, a crdito y con cheque, todos estos conceptos son muy parecidos. En esta situacin, es posible organizarlos en una jerarqua de clases de generalizacin/especializacin en la cual, la superclase Pago representa el concepto ms general y las subclases, conceptos ms especializados.
130
Pago
PagoEnEf ectivo
PagoACr edito
PagoCon Cheque
La generalizacin es la actividad de identificar elementos comunes entre los conceptos y definir relaciones de superclase (concepto general) y subclase (concepto especializado).
La identificacin de herencia es til en un modelo del dominio porque su presencia nos permite entender los conceptos en trminos ms generales, refinados y abstractos.
Esto nos lleva a una economa de expresin, a mejorar la comprensin y a reducir la informacin repetida.
131
Agregacin
Se utiliza para modelar las relaciones todo/parte entre las abstracciones. El todo se denomina compuesto. La agregacin se representa en UML mediante un rombo hueco o relleno en el extremo del compuesto de una relacin todo/parte. El nombre de la relacin de agregacin se excluye a menudo puesto que se piensa habitualmente como tiene-parte.
132
Mano 1 1..7
Dedos
La agregacin de composicin significa que la parte es un miembro de un nico objeto compuesto y, que existe una dependencia de existencia y disposicin de la parte sobre el compuesto. Por ejemplo existe una relacin de composicin entre la mano y un dedo.
La composicin y su implicacin de dependencia de existencia indica que los objetos software compuestos crean (o provocan la creacin de) los objetos software de la parte, por ejemplo, cuando uno piensa en la mano que incluye los dedos, decimos se ha formado una mano, entendemos que eso significa que tambin se han formado los dedos.
La composicin implica pues que, solamente el compuesto posee la parte.

133
Agregacin
Agregacin compartida. Significa que la multiplicidad (cardinalidad) en el extremo del compuesto podra ser mas de uno, y se representa por un rombo hueco. Esto implica que la parte podra estar simultneamente en muchas instancias del compuesto. Este tipo de agregacin existe en conceptos no fsicos.
134
PaqueteUML
EelementoUML
Por ejemplo, se podra considerar que un paquete UML agrega sus elementos. Pero un elemento podra ser referenciado en ms de un paquete (pertenece a un paquete y es referenciado en otros). Considere mostrar una agregacin cuando: El tiempo de vida de la parte est ligada al tiempo de vida del compuesto, es decir, existe una dependencia de creacin-eliminacin de la parte en el todo. Existe un ensamblaje obvio todo-parte fsico o lgico.
135
UNIDAD IV
DISEO
136
Diseo e implementacin de software

El diseo es el primer paso de la fase de desarrollo de cualquier producto o sistema de ingeniera. definicin: el proceso de aplicar distintas tcnicas y principios con el propsito de definir un dispositivo, proceso o sistema con los suficientes detalles como para permitir su realizacin fsica.
137
Diseo en la ingeniera de software

El diseo de software es la ltima accin de la ingeniera correspondientes a la actividad de modelado, la cual establece una plataforma para la construccin (generacin de cdigo y pruebas). Cada uno de los elementos de anlisis proporciona la informacin necesaria para crear los cuatro modelos que se requieren para una especificacin completa de diseo.
138

Modelos de diseo: Diseo de datos-clase: transforma los modelos de anlisis y clases en las clases de diseo y las estructuras de datos que se requieran para implementar el software. Las relaciones entre clases, los atributos de las clases y otras notaciones proporcionan la base para la actividad de diseo de datos. Diseo arquitectnico: define la relacin entre los elementos estructurales ms importantes del software, los estilos arquitectnicos y patrones de diseo que pueden usarse para satisfacer los requisitos del sistema y las restricciones que afectan la manera en que se pueden implementar los patrones arquitectnicos.
139

Modelos de diseo: Diseo de la interfaz: describe la forma en que el software se comunica con los sistemas que interacta con l y con los humanos que lo utilizan. Los escenarios de uso y los modelos de comportamiento proporcionan mucha de la informacin que se requiere para el diseo de la interfaz. Diseo a nivel de componente: transforma los elementos estructurales de la arquitectura del software en una descripcin procedimental de los componentes de ste.
140
Diseo
Durante el diseo se toman decisiones que afectan al xito de la construccin del software y la facilidad con la que se podr mantener. La importancia del diseo del software se puede expresar con una sola palabra: CALIDAD El diseo proporciona las representaciones del software que pueden evaluarse respecto a la calidad. El diseo de software sirve como fundamento para todas las actividades subsecuentes de la IS y del soporte del sistema. Sin diseo se construye un sistema inestable; que fallar en cuanto se realicen cambios pequeos; que ser difcil de probar; cuya calidad no se pueda evaluar sino hasta etapas tardas, cuando queda poco tiempo y se ha gastado mucho 141 dinero en l.
Mantenimient o
Mantenimiento Prueba Implementacin Prueba Implementacin
Diseo Con diseo

Sin diseo
142
El proceso de diseo
El diseo del software es un proceso iterativo mediante el cual los requisitos se traducen en un plano para construir el software. El diseo se representa en un grado alto de abstraccin, el cual puede rastrearse de forma directa hasta conseguir el objetivo especfico el sistema y requisitos ms detallados de comportamiento, funcionales y de datos. A medida que ocurren las iteraciones se consigue un refinamiento que conduce a representaciones de diseo a grados mucho ms bajos de abstraccin. A travs del proceso de diseo la calidad de ste debe ser evaluada. McGlaughlin sugiere tres caractersticas que sirven como gua en la evaluacin de un buen diseo:
Debe implementar todos los requisitos explcitos contenidos en el 143 modelo de anlisis, y debe ajustarse a todos los requisitos implcitos que desee el cliente.
El proceso de diseo
Debe ser una gua legible y comprensible para los que generan el cdigo y realizan las pruebas, as como para quienes dan el soporte (mantenimiento). Debe proporcionar una imagen completa del software (identificndose los dominios de datos, funcional y de comportamiento) desde una perspectiva de implementacin. De hecho cada una de estas caractersticas es una meta del proceso de diseo, pero: Cmo alcanzar cada una de ellas?
144
Directrices de calidad para el diseo

Se presentan las siguientes directrices con el fin de evaluar la calidad de una representacin de diseo: 1. Un diseo debe presentar una estructura arquitectnica que: a) Se haya creado mediante patrones de diseo reconocibles. b) La integren componentes que exhiban buenas caractersticas de diseo. c) Pueda implementarse de manera evolutiva 2. Un diseo debe ser modular, esto es, el software deber dividirse de manera lgica en elementos o subsistemas. 3. Un diseo debe contener distintas representaciones de los datos, la arquitectura, las interfases y los componentes. 4. Un diseo debe conducir a estructuras de datos que sean apropiadas para las clases que habrn de implementarse.
145
Directrices de calidad para el diseo

Un diseo debe conducir a componentes que presenten caractersticas funcionales independientes. 6. Un diseo debe conducir a interfases que reduzcan la complejidad de las conexiones entre los componentes y el ambiente externo. 7. El diseo debe obtenerse por medio de un mtodo repetible que se base en la informacin obtenida durante le anlisis de requisitos del software. 8. El diseo debe representarse por medio de una notacin que comunique de manera eficaz su significado. Esto se puede lograr aplicando principios fundamentales de diseo, una metodologa sistemtica y una revisin cuidadosa.
5.
146
Conceptos de diseo
M. A. Jackson dijo: El comienzo de la sabidura para un ingeniero de software es reconocer la diferencia entre hacer que un programa funcione, y conseguir que lo haga del modo correcto. Los conceptos fundamentales de diseo de software ofrecen el marco de trabajo necesario para hacer las cosas del modo correcto.
147
Conceptos de diseo Abstraccin

Es una de las formas fundamentales en las que el humano enfrenta la complejidad (Grady Booch). La abstraccin es el examen selectivo de ciertos aspectos de un problema. Su finalidad es aislar aquellos aspectos que sean importantes para algn objetivo y suprimir los aspectos que no lo sean. La abstraccin siempre debe hacerse con algn objetivo prefijado, porque el propsito determina lo que es y lo que no es importante. Es posible efectuar muchas abstracciones diferentes de la misma cosa, dependiendo del propsito para el cual se hagan esas abstracciones.
148

Cuando se considera una solucin modular para cualquier problema, pueden exponerse muchos grados de abstraccin: En un alto grado de abstraccin, se establece una solucin en trminos generales, usando el lenguaje del entorno del problema. A medida que nos movemos a travs del proceso de diseo, se reduce el nivel de abstraccin proporcionando una descripcin ms detallada de la solucin. Finalmente, se alcanza el nivel inferior de abstraccin cuando se construye el cdigo.
149

Conforme cambian los diferentes grados de abstraccin se trabaja para crear: Abstracciones procedimentales. La cual se refiere a una secuencia de instrucciones que tiene una funcin especfica y limitada. El nombre de la abstraccin procedimental implica estas funciones pero se omiten detalles especficos. Por ejemplo la palabra abrir para una puerta; implica una larga secuencia de pasos procedimentales (caminar a la puerta, alcanzar la manija, darle vuelta a la manija, empujar la puerta, etc.). Abstracciones de datos. es una coleccin nombrada de datos que describen un objeto de datos, un ejemplo podra ser PUERTA ya que comprende un conjunto de atributos que la describen (tipo de puerta, direccin de apertura, mecanismo de apertura, peso, dimensiones).
150
Conceptos de diseo Arquitectura

En la construccin de edificios, la arquitectura juega un rol central. La arquitectura de un edificio se describe usando un conjunto de planos, que juntos, representan todos los aspectos del edificio. sta describe el edificio desde diferentes puntos de vista, como electricidad, plomera, estructura, etc. El arquitecto es la persona encargada del proyecto completo. Es el responsable de asegurar que el edificio ser slido, costo-efectivo y satisfactorio para el cliente. La arquitectura del software es similar. sta juega el papel central en la ingeniera de software e involucra el desarrollo de una variedad de vistas de alto nivel del sistema. La arquitectura del software es el proceso de disear la organizacin global de un sistema software, incluye la divisin del software en subsistemas, decisiones de cmo van a interactuar los subsistemas y determinar sus interfaces.
151

Los ingenieros de software discuten todos los aspectos del diseo de un sistema en trminos del modelo arquitectnico. Por lo tanto, las decisiones hechas mientras este modelo est siendo desarrollado, tienen un profundo impacto sobre el resto de las actividades del proceso de diseo. El modelo arquitectnico es el ncleo del diseo, as que todos los miembros del equipo de desarrollo necesitan entenderlo. Hay 4 razones principales por las que es necesario desarrollar un modelo arquitectnico: 1. Permitir un mejor entendimiento del sistema 2. Permitir que la gente trabaje en piezas individuales del sistema en forma aislada. 3. Prepararse para la extensin del sistema. 4. Facilitar la reusabilidad.
152

1.
2.
Permitir un mejor entendimiento del sistema: Conforme un sistema se va haciendo ms y ms complejo, hacerlo entendible es mucho ms difcil. Un buen modelo arquitectnico permite que la gente entienda cmo el sistema trabaja en conjunto, tambin define los trminos que la gente usa cuando se comunica con los dems acerca de detalles de bajo nivel. Permitir que la gente trabaje en piezas individuales del sistema en forma aislada: El trabajo de desarrollo de un sistema de software complejo debe ser distribuido entre una gran cantidad de gente. La arquitectura permite la planeacin y coordinacin de este trabajo distribuido. La arquitectura debe proveer informacin suficiente para que el trabajo de un individuo o equipo pueda integrarse ms tarde para formar el sistema final. Esta es la razn por la que las interfaces y las interacciones dinmicas entre los subsistemas son una parte importante de la arquitectura.
153

3.
4.
Prepararse para la extensin del sistema: Con un modelo arquitectnico completo, se hace ms fcil planear la evolucin del sistema. Los subsistemas que se preve sern parte de futuras versiones pueden ser incluidos en la arquitectura, incluso aunque no sean desarrollados inmediatamente. Facilitar la reusabilidad: El modelo arquitectnico hace visible a cada componente del sistema. Analizando la arquitectura podemos descubrir aquellos componentes que puedan ser obtenidos de proyectos pasados. Tambin se pueden identificar componentes que tengan un alto potencial de reusabilidad. Hacer una arquitectura tan genrica como sea posible es la clave para asegurar la reusabilidad.
154

Contenido de un buen diseo arquitectnico: Anlisis lgico en los subsistemas, esto se muestra usando diagramas de paquetes. La dinmica de interaccin entre componentes (en tiempo de ejecucin), esto se expresa usando diagramas de interaccin y diagramas de actividades. Los datos que sern compartidos entre los subsistemas, se expresa tpicamente usando diagramas de clases. Los componentes que existirn en tiempo de ejecucin y las mquinas o dispositivos sobre los cuales estarn localizados, esta informacin se expresa usando diagrama de componentes o diagramas de despliegue.
155
Conceptos de diseo Modularidad
El software se divide en componentes con nombres independientes y que es posible abordar en forma individual. Estos componentes llamados mdulos se integran para satisfacer los requisitos del problema. Se ha dicho que la modularidad es el atributo particular del software que permite que un programa sea manejable de manera intelectual. El software monoltico (un gran programa compuesto de un nico mdulo) no puede ser entendido fcilmente por un lector.
156

Para ilustrar lo anterior consideremos lo siguiente: Sea C(x) una funcin que define la complejidad de un problema x. E(x) una funcin que define el esfuerzo (en tiempo) requerido para resolver un problema x. Para 2 problemas p1 y p2, si C(p1) > C(p2) entonces E(p1) > E(p2) Obviamente se tarda ms tiempo en resolver un problema difcil.
157

Se ha encontrado otra propiedad interesante: C(p1+p2) > C(p1) + C(p2) Esto indica que la complejidad de un problema compuesto por p1 y p2 es mayor que la complejidad total considerando cada problema por separado. Por lo tanto: E(p1+p2) > E(p1) + E(p2) Esto nos lleva a la conclusin del tipo divide y vencers, es ms fcil resolver un problema cuando se divide en trozos ms manejables.
158

De acuerdo a las desigualdades anteriores nos hacemos la siguiente pregunta: Si partimos el software indefinidamente, el esfuerzo requerido para desarrollarlo sera insignificantemente pequeo? Esta afirmacin no es cierta, desgraciadamente intervienen otros factores, mientras ms mdulos haya, el nmero de interfaces crece y se hace ms complicado integrar los mdulos.
159

Un diseo y el programa resultante se modularizan de manera que el desarrollo se pueda planear con mayor facilidad; se puedan definir y entregar incrementos del software; los cambios puedan ajustarse con mayor facilidad; las pruebas y la eliminacin de errores se pueda hacer con mayor eficiencia, y el mantenimiento se pueda realizar sin efectos colaterales de consideracin.
160
Conceptos de diseo
Ocultamiento de Informacin
El concepto de modularidad conduce a todos los diseadores de software a plantearse una pregunta fundamental: Cmo puede descomponerse una solucin de software para obtener el mejor conjunto de mdulos? El principio de ocultamiento de la informacin sugiere que los mdulos deben especificarse y disearse de manera que la informacin (procedimiento y datos) que est dentro del mdulo sea inaccesible para otros mdulos que no necesitan esa informacin. El ocultamiento implica que puede conseguirse una modularidad efectiva al definir un conjunto de mdulos independientes que se comuniquen entre si y que intercambien slo la informacin necesaria para lograr la funcin del software.
161
Conceptos de diseo
Ocultamiento de Informacin
El ocultamiento define y fortalece las restricciones de acceso para los detalles de procedimiento dentro de un mdulo y para cualquier estructura de datos que utilice el mdulo. El uso del ocultamiento de informacin como un criterio de diseo para sistemas modulares, proporciona los mayores beneficios cuando se requieren modificaciones, durante el proceso de prueba y despus durante le mantenimiento. Esto significa que como la mayora de los datos y procedimientos estarn ocultos para las otras partes del software, ser menos probable que los errores introducidos inadvertidamente durante las modificaciones se propaguen a otros lugares del software.
162
Conceptos de diseo
Independencia Funcional
El concepto de independencia funcional (IF) es la suma directa de la modularidad y de los conceptos de abstraccin y ocultamiento de informacin. La IF se consigue al desarrollar mdulos con una funcin determinante y una aversin a la interaccin excesiva con otros mdulos. Esto es, disear el software de tal manera que cada mdulo aborde una subfuncin especfica de los requisitos y tenga una sola interfaz. Por qu es importante la independencia?
163
Conceptos de diseo
El software con una modularidad efectiva, es decir con mdulos independientes, es ms fcil de desarrollar porque la funcin se puede fraccionar y las interfaces se simplifican (por ejemplo: cuando el desarrollo se realiza en equipo). Los mdulos independientes son ms fciles de mantener y probar porque se limitan los efectos secundarios que originan las modificaciones al diseo o al cdigo, se reduce la propagacin de errores. Es posible emplear mdulos reutilizables. En resumen la independencia funcional es la clave para lograr la calidad del software.
164
Conceptos de diseo
La independencia funcional se aplicando dos criterios cualitativos:

evala
Cohesin Acoplamiento.
TAREA: INVESTIGAR AMPLIAMENTE ESTOS CONCEPTOS (ENTREGAR ESCRITA A MANO) FECHA:

165
Conceptos de diseo
Refinamiento

El refinamiento es una estrategia de diseo descendente que propuso inicialmente Niklaus Wirth. El refinamiento es un proceso de elaboracin. Se inicia en el enunciado de una funcin (o una descripcin de datos) que se define con un alto grado de abstraccin, es decir el enunciado describe la funcin o los datos de manera conceptual pero no proporciona informacin acerca de los trabajos internos de la funcin o de la estructura interna de los datos. El refinamiento hace que el diseador trabaje sobre el enunciado original y que conforme se realiza cada refinamiento (elaboracin) sucesivo proporcione ms y ms detalles.
166
Conceptos de diseo
La abstraccin y el refinamiento son conceptos complementarios. La abstraccin le permite al diseador especificar procedimientos y datos sin considerar detalles de grado menor. El refinamiento ayuda al diseador a revelar los detalles de grado menor mientras se realiza el diseo.
167
El modelo de diseo
El modelo de diseo puede verse en dos dimensiones diferentes: La dimensin del proceso: indica la evolucin del modelo de diseo conforme se ejecutan las tareas de diseo como una parte del proceso del software. La dimensin de abstraccin: representa el grado de detalle a medida que cada elemento del modelo de anlisis se transforma en un equivalente del diseo y despus se refina de una manera iterativa. En la figura se ilustra lo anterior.
168
alto
Modelo de anlisis Dimensin de Abstraccin
Diagrama de clases Paquetes de anlisis Diagramas de flujo de datos Casos de uso Diagrama de casos de uso Diagrama de clases Paquetes de anlisis Diagramas de flujo de datos
Narrativas de procesamiento Requisitos: Narrativas de procesamiento Diagramas de estado Restricciones Diagramas de estado Diagramas de secuencia Interoperabilidad Diagrama de secuencia Objetivos y configuracin Realizaciones de clases de diseo Subsistemas Diagramas de colaboracin Diseo de interfase tcnica Diseo de navegacin Diseo de IGU Diagramas de componente Clases de diseo Diagramas de actividad Realizacin de clases de diseo Subsistemas Diagramas de colaboracin Diagramas de componente
Diagramas de secuencia
Modelo de diseo
Refinamientos a: Realizaciones de clases Refinamientos a: Clases de diseo Diagramas de actividad Diagramas de secuencia
Clases de diseo
Diagramas de actividad Diagramas de componente Diagramas de secuencia
bajo
de diseo Subsistemas Diagramas de colaboracin
Diagramas de despliegue
Elementos Arquitectnicos
Elem. de interfaz
Elem. al nivel de componentes
Elem. al nivel de despliegue 169
Dimensin del proceso
El modelo de diseo
Elementos del diseo de datos
El diseo de datos crea un modelo de datos o informacin que se representa con un alto grado de abstraccin. Despus este modelo de datos se refina en representaciones que tengan una implementacin especfica y que puedan procesarse mediante el sistema basado en computadora. El diseo de datos tiene una profunda influencia sobre la arquitectura de software que los debe procesar. La estructura de los datos siempre ha sido una parte importante del diseo de software: Al nivel de los componentes del sistema, las estructuras de datos y los algoritmos con que se manipulen son esenciales para la creacin de aplicaciones de alta calidad.
170
El modelo de diseo
Elementos del diseo de datos
Al nivel de la aplicacin, la traduccin de un modelo de datos a una base de datos es esencial para alcanzar los objetivos de negocio de un sistema. Al nivel de negocios, la coleccin de informacin almacenada en bases de datos dispersas y reorganizadas en un almacn de datos permite la explotacin de datos o el descubrimiento de un conocimiento que puede tener un impacto sobre el xito del mismo negocio. En cada caso, el diseo de datos juega un papel importante.
171
El modelo de diseo
Elementos del diseo Arquitectnico
Los elementos del diseo arquitectnico dan una visin general del software. El modelo arquitectnico se obtiene a partir de 3 fuentes: 1. La informacin acerca del dominio de la aplicacin. 2. Los elementos de anlisis especfico (DFD, diagramas de clases y sus relaciones) 3. La disponibilidad de patrones y estilos arquitectnicos.
172
El modelo de diseo
Elementos de diseo de Interfaz
Los elementos del diseo de la interfaz muestran como fluye la informacin hacia el sistema o fuera del sistema y cmo ste est comunicado entre los componentes definidos como parte de la arquitectura. Existen tres elementos importantes del diseo de interfaz: 1. La interfaz con el usuario. 2. Interfaces externas a otros sistemas, artefactos, redes u otros productores o consumidores de informacin. 3. Interfaces internas entre varios componentes de diseo. Estos elementos de diseo de interfaz permiten al software comunicarse de manera externa y permiten la comunicacin y colaboracin interna entre los componentes que integran la arquitectura del software.
173
El modelo de diseo Elementos de diseo al nivel de componentes

El diseo al nivel de componentes para software describe por completo el detalle interno de cada componente del software. Para lograrlo el diseo el diseo al nivel de componente define estructuras de datos para todos los objetos locales, as como detalle algortmico para todo el procesamiento que ocurre dentro de un componente y una interfaz que permite el acceso a todas las operaciones de los componentes (comportamientos).
174
Diagrama de componente en UML para ManejoSensor

ManejoSensor
Sensor
En esta figura se representa un componente llamado ManejoSensor. El componente est conectado a una clase llamada Sensor, la cual est asignada al componente mediante una flecha punteada. El componente ManejoSensor realiza todas las funciones asociadas con los sensores entre las que se encuentran monitoreo y configuracin.
175
El modelo de diseo
Elementos de diseo a nivel de despliegue
Los elementos de diseo a nivel del despliegue indican como se ubicarn las funcionalidad y los subsistemas dentro del entorno computacional fsico que soportar al software. Por ejemplo, los elementos de HogarSeguro estn configurados para operar dentro de tres entornos de computacin primarios: una PC domstica, el panel de control de HogarSeguro y un servidor ubicado en CPI Corp. (lo que proporciona acceso al sistema a travs de Internet).
176
Diagrama de despliegue en UML para HogarSeguro

Panel de Control Servidor de CPI Seguridad AccesoPropietario
Computadora personal Acceso ext Vigilancia
Se muestran tres ambientes computacionales. Se indican los subsistemas (funcionalidad) que se alojan dentro de cada elemento de computo. Por ejemplo la computadora personal aloja subsistemas que implementan seguridad, vigilancia, caractersticas de comunicacin y unsubsistema de acceso externo para controlor los accesos al sistema HogarSeguro. Cada subsistema debe ser eleaborado 177 que para indicar los componentes implementa.
Seguridad
comunicacion
Diseo de software basado en patrones

Conforme se obtiene experiencia en el desarrollo de software OO, se empieza a notar que muchas partes de los diseos reaparecen, con solamente algunos insignificantes cambios, en muchos diferentes sistemas o subsistemas. Estos aspectos recurrentes de diseo son llamados patrones de diseo. Muchos de ellos han sido documentados sistemticamente para que todos lo desarrolladores de software los usen. Definiciones: Un patrn es un par problema/solucin con nombre que se puede aplicar a nuevos contextos, con consejos acerca de cmo aplicarlo en nuevas situaciones. Un patrn es el resultado de una solucin reusable para un problema general encontrado en un contexto particular. Un patrn de diseo puede describirse empleando la plantilla que se muestra a continuacin: 178
Plantilla del patrn de diseo

Nombre del patrn: describe la esencia del patrn en un nombre corto pero expresivo. Intencin: Describe el patrn y lo que hace. Tambin-conocido-como: lista de los sinnimos para el patrn. Motivacin: proporciona un ejemplo del problema. Aplicabilidad: situaciones especficas de diseo en las cuales es aplicable Las fuerzas de diseo son aquellas el patrn caractersticas del problema (requisitos nopara funcionales) y Estructura: describe las clases que se requieren implementar el aquellos atributos de la patrn. solucin que restringen la Participantes: describe las responsabilidades de las clases que se forma en se puede requieren para implementar el patrn. desarrollar el diseo. Colaboraciones: describe cmo colaboran los participantes para llevar a cabo sus responsabilidades. Consecuencias: describe las fuerzas de diseo que afectan al patrn y los intercambios potenciales que deben considerarse cuando se implementa el patrn. Patrones relacionados: patrones de diseo relacionados mediante referencias cruzadas. 179
Diseo de software basado en patrones

Un buen patrn debe ser tan general como sea posible, conteniendo una solucin que ha sido provista para resolver el problema efectivamente en el contexto indicado. El patrn debe ser descrito en una forma fcil de entender, de modo que la gente pueda determinar cuando y como usarlo. Estudiar patrones es una manera efectiva para aprender de la experiencia de otros.
180
Diseo Arquitectnico
El diseo arquitectnico representa la estructura de datos y los componentes de programa necesarios para construir un sistema computacional. Asume el estilo arquitectnico que tomar el sistema y las interrelaciones entre todos los componentes arquitectnicos de un sistema. La arquitectura del software de un programa o sistema de computo es la estructura del sistema, que incluyen los componentes del software, las propiedades visibles externamente de los componentes y las relaciones entre ellos
181
Diseo Arquitectnico
La arquitectura es la representacin que permite que un ingeniero de software: 1. Analice la efectividad del diseo para cumplir con los requisitos establecidos. 2. Considere opciones arquitectnicas en una etapa en que an resulta relativamente fcil hacer cambios al diseo y, 3. Reduzca los riesgos asociados con la construccin del software.
182
Diseo Arquitectnico
Razones claves por las cuales la arquitectura del software es importante: Las representaciones de la arquitectura del software permiten la comunicacin entre todas las partes (participantes) interesadas en el desarrollo del sistema. La arquitectura destaca las decisiones iniciales relacionadas con el diseo que tendrn un impacto profundo en todo el trabajo de la IS que le sigue, y tambin en el xito final del sistema. La arquitectura constituye un modelo relativamente pequeo e intelectualmente comprensible de cmo est estructurado el sistema y como trabajan juntos sus componentes.
183
Estilos y patrones arquitectnicos

Un estilo arquitectnico es un mecanismo descriptivo para diferenciar una construccin de otra (en el contexto de la construccin de edificios). Pero algo ms importante es que el estilo arquitectnico es una plantilla para la construccin, resultar necesario proporcionar mayores detalles, agregar caractersticas personales, etc. Pero el estilo que se haya elegido es el que gua el trabajo del constructor. El software que se construye para sistemas de computo puede mostrar uno o muchos estilos arquitectnicos. Cada estilo describe una categora de sistemas que abarca: 1. Un conjunto de componentes que realizan una funcin requerida por el sistema. 2. Un conjunto de conectores que permiten la comunicacin, coordinacin y cooperacin entre los componentes. 3. Restricciones que definen cmo se integran los componentes para formar el sistema. 4. Modelos semnticos que permiten a un diseador, mediante el anlisis de las propiedades conocidas de las partes que lo integran, 184 comprender las propiedades generales de un sistema.
Un estilo arquitectnico es una transformacin impuesta al diseo de todo un sistema. El objetivo es establecer una arquitectura para todos los componentes del sistema. Un patrn arquitectnico tambin impone una transformacin en el diseo de una arquitectura. Sin embargo un patrn difiere de un estilo en varios elementos fundamentales:
185

El alcance de un patrn es menor, ya que se concentra en un aspecto, en lugar de hacerlo en toda la arquitectura. 2. Un patrn impone una regla sobre la arquitectura pues describe la manera en que el software manejar un aspecto de su funcionalidad al nivel de la infraestructura (concurrencia). 3. Los patrones arquitectnicos tienden a abarcar aspectos especficos del comportamiento dentro del contexto de la arquitectura. Los patrones se usan junto con un estilo arquitectnico para determinar la forma de la estructura general de un sistema.
1.
186
Arquitecturas de uso comn en el software
Arquitectura centrada en datos: en el centro de esta arquitectura se encuentra un almacn de datos (base de datos o archivos); otros componentes tienen acceso a l y cuentan con la opcin de agregar, eliminar o modificar los datos de ese almacn. Una arquitectura centrada en datos promueve la capacidad de integracin, esto significa que es posible cambiar componentes existentes y agregar nuevos componentes cliente a la arquitectura sin ningn problema, ya que los componentes cliente operan de manera independiente.
187
Arquitectura centrada en datos

Software cliente Software cliente
Software
cliente
Software cliente Almacn de datos Software cliente
Software cliente Software cliente
Software cliente
188
Arquitectura de flujo de datos: Esta arquitectura se aplica cuando los datos de entrada se habrn de transformar en datos de salida mediante una serie de componentes para el clculo o la manipulacin. Se representa mediante una estructura de tuberas y filtros, en la que los componentes se denomina filtros que estn conectados por tuberas que transmiten datos de un componente al siguiente. Cada filtro funciona sin tomar en cuenta el flujo de los componentes (ascendente o descendente), est diseado para esperar la entrada de datos con cierta forma y producir su salida de una manera especfica. No es necesario que un filtro conozca el funcionamiento de los filtros vecinos.
189
Arquitectura de flujo de datos

Filtro Filtro
Filtro
Filtro
Filtro
Filtro Filtro Tuberas y Filtros Filtro
Filtro
Filtro
190
Arquitectura de llamada de retorno: Este estilo permite que un diseador de software obtenga una estructura de programa relativamente fcil de modificar. Existen dos sub-estilos: Arquitectura de programa principal/subprograma: esta estructura clsica separa la funcin en una jerarqua de control donde un programa principal invoca a varios componentes de programa, que a su vez pueden invocar a otros componentes. Arquitectura de llamada de procedimiento remoto: los componentes de una arquitectura de programa principal/subprograma se distribuyen entre varias computadoras de una red.
191
Arquitectura de programa principal/subprograma

Programa Principal
Subprograma
controlador
Subprograma
controlador
Subprograma controlador
Subprograma
controlador
Subprograma
controlador
192
Arquitectura orientada a objetos: Los componentes de un sistema encapsulan los datos y las operaciones que deben aplicarse para manipular los datos. La comunicacin y coordinacin entre componentes se consigue mediante el paso de mensajes. Arquitectura estratificada: Aqu se definen varias capas, cada una de ellas realiza operaciones que se acercan progresivamente al conjunto de instrucciones de la mquina. En la capa externa los componentes sirven a las operaciones de interfaz de usuario. En la capa interna los componentes sirven como interfaz con el sistema operativo. Las capas intermedias proporcionan servicios de utilera y de software de aplicaciones.
193
Arquitectura estratificada
Capa de la interfaz de usuario
Capa de la aplicacin Capa de utileras Capa central
194

Estos estilos arquitectnicos son algunos de los que se dispone para disear el software. El estilo arquitectnico o la combinacin de estilos se elige dependiendo de las caractersticas y restricciones del sistema que se habr de construir. En muchos casos ser apropiado ms de un estilo. Por ejemplo en muchas aplicaciones de base de datos se combina un estilo por capas (apropiado para casi todos los sistemas) con una arquitectura centrada en datos.
195

Curso de Ingenieria de Software

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Curso de Ingenieria de Software

Enviado por

Direitos autorais:

Formatos disponíveis

Instituto Tecnolgico de Culiacn Ingeniera en Sistemas Computacionales Ingeniera de Software MC MARCO ANTONIO RODRIGUEZ AVILES

Caractersticas diferentes del software con respecto al hardware

Categoras del software

Preocupacin por la industria

Hacia la Ingeniera de Software

Hacia la Ingeniera de Software

Mitos del software

Mitos del software

Mitos del software

Mitos del software

Mitos del software

Mitos del software

Mtricas para la productividad y calidad del software

Mtricas para la productividad y calidad del software

Medicin del software

Medicin del software

Medicin del software

Medicin del software

Clasificacin de las mtricas del software

Tareas de la ingeniera de requisitos

Tareas de la IR Obtencin de los requisitos

Tareas de la IR Obtencin de los requisitos

Tareas de la IR Obtencin de los requisitos

Tareas de la IR Obtencin de los requisitos

Tareas de la IR Obtencin de los requisitos

Tareas de la IR Obtencin de los requisitos

Tareas de la IR Obtencin de los requisitos

Tareas de la IR Obtencin de los requisitos

Escenarios del usuario

Productos de trabajo de la Obtencin

Desarrollo de casos de uso

Desarrollo de casos de uso

Desarrollo de casos de uso

Desarrollo de casos de uso: un ejemplo

Desarrollo de casos de uso

Desarrollo de casos de uso: algunas definiciones

Caso de uso UC1: Proceso de venta

Caso de uso UC1: Proceso de venta

Caso de uso UC1: Proceso de venta

Caso de uso UC1: Proceso de venta

Diagrama de casos de uso

Servicio de autorizacin de pagos

<<actor>> Sistema de actividad de ventas

Manejo de seguridad Manejo de usuarios

Tip para escribir casos de uso exitosos

Construccin del modelo de anlisis

Elementos del modelo de anlisis

Elementos basados en escenarios

Realizar reuniones Listas de funciones y clases

Definir actores Escribir el escenario Escribir el escenario

Diagrama de actividades para la obtencin de requisitos

Elementos basados en clases

Diagrama de clases (parcial)

Descripcion precio articuloID getPrecio()

Objetivos del modelo de anlisis

Enfoques del modelado del anlisis

Enfoques del modelado del anlisis

Conceptos del modelado de datos (objetos de datos)

Conceptos del modelado de datos (objetos de datos)

REPRESENTACIN TABULAR DE OBJETOS DE DATOS

Nombrar una ocurrencia del objeto de datos.

Conceptos del modelado de datos (objetos de datos)

Conceptos del modelado de datos (objetos de datos)

Conceptos del modelado de datos (objetos de datos)