Beruflich Dokumente
Kultur Dokumente
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
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.
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.
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 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
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 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
18
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
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
21
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
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
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
Tareas de la IR Inicio
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
Tareas de la IR Inicio
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
Tareas de la IR Inicio
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
Tareas de la IR Inicio
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
Tareas de la IR Inicio
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
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.
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
48
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
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
Cajero
Entrada de dinero
Analizar actividad
Administrador
60
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
Obtener requisitos
priorizacin formal? si
no
Utilizar QFD Para jerarquizar requisitos
Jerarquizar informal
Completar la plantilla
65
Venta
fecha hora getTotal()
Especificacion DelProducto
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
74
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
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
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.
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
posee
b) Relaciones entre objetos de datos persona Asegurada para manejar automvil
81
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
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).
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
Cmaras
Propietario de la casa
Configurara sistema
Configurar alarma
91
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
Contraseas/ID vlidas
Selecciona una Funcin importante
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
93
97
Panel de
Control
Despliegue de informacin
Software de HogarSeguro
Tipo de alarma
Alarma
Estatus del sensor Sensores Tonos del nmero telefnico Lnea Telefnica
99
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
Peticin de Configuracin
Iniciar/detener
Contrasea
Datos de Configuracin
Desplegar informacin
Alarma
Lnea Telefnica
102
Sensores
Estatus del Sensor
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
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
Datos de configuracin
Datos de alarma
Tipo de alarma
Nmero telefnico
Marcar telfono
Sensores
105
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
112
113
Vuelo
destino
Peor
Destino es un concepto complejo
Vuelo
Vuela-a
Aeropuerto
Mejor
115
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
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
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; };
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.
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
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
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
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
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
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
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
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
Independencia Funcional
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
Independencia Funcional
evala
Cohesin Acoplamiento.
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
Independencia Funcional
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
Diagramas de despliegue
Elementos Arquitectnicos
Elem. de interfaz
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
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
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 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
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
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
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
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
Subprograma
controlador
Subprograma
controlador
Subprograma controlador
Subprograma
Subprograma controlador
Subprograma controlador
Subprograma controlador
Subprograma controlador
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
194