Está en la página 1de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

Unidad N 1: Anlisis en el Proceso Unificado de Desarrollo 1.1 El Flujo de Trabajo de Anlisis: Introduccin: Se analizan los requisitos refinndolos y estructurndolos con el fin de comprenderlo de manera precisa y para que estos sean fciles de mantener. El objetivo del anlisis es generar un modelo de anlisis, el cual se centra en lo que es sistema debe hacer dejando los detalles del como lo har al workflow de diseo. Modelo de anlisis: Es una aproximacin al modelo de diseo, siendo un modelo por si mismo. Es una entrada en las actividades de diseo e implementacin. Brinda una estructura centrada en el mantenimiento (flexible ante cambios). Ayuda a refinar y estructurar los requerimientos. Ayuda a razonar sobre aspectos internos del sistema (recursos). Ofrece mayor poder expresivo y mayor formalizacin (diag. Interaccin). Reglas generales para un modelado de anlisis exitoso: El modelado de anlisis siempre est en el lenguaje del negocio. Crear modelos (diagramas) que aclare parte importante del comportamiento del sistema. Distinguir dominio del problema del dominio de solucin y centrarse en el dominio del problema. Minimizar acoplamiento (asociacin entre clases crea acoplamiento entre ellas) Crear un modelo de utilidad para todos los grupos de decisin. Cundo hacer Anlisis?: Mediante la realizacin separada del anlisis se puede, utilizando el resultado del mismo, planificar el trabajo de diseo e implementacin. Debido a que el anlisis proporciona una visin general del sistema se puede obtener una mejor comprensin de un sistema ya desarrollado. Es bueno realizar anlisis cuando el sistema se implementa ms de una vez utilizando diferentes tecnologas. Realizar anlisis cuando el sistema se construye utilizando un sistema heredado complejo sin necesidad de profundizar en detalles de diseo e implementacin. 1.1.1 El Rol del Anlisis en el Ciclo de Vida del Software: El trabajo principal empieza al final de la fase de Inicio y es el foco principal de la fase de Elaboracin en la cual se obtiene una estructura estable y slida, creando modelos que capturan el comportamiento del sistema. Cmo se emplea el Anlisis en los proyectos? El modelo de anlisis se puede: utilizar y mantener su consistencia a lo largo del ciclo de vida del software, o utilizarse como una herramienta transitoria e intermedia o puede no utilizarse. 1.1.2 Artefactos del Anlisis: Modelo de Anlisis: jerarqua de paquetes de anlisis que contienen clases de anlisis y - Qu hace una buena realizaciones de CU-anlisis. clase de Clases de anlisis: representa una abstraccin de una o varias clases del diseo del anlisis? sistema. Caractersticas: - Responsabilidad: Se centra en el tratamiento de requerimientos funcionales. descripcin textual de un Su comportamiento se define mediante responsabilidades. conjunto cohesivo del comportamiento de una - Reglas Define atributos reconocibles en el dominio del problema. clase. generales de Participa en relaciones clases de Debe mapearse con conceptos del negocio del mundo real. anlisis. Existen tres estereotipos (estandarizados en UML) Clase Interfaz: modelan las interacciones entre el sistema y sus actores, es decir, que modela las partes del sistema que depende de los actores. Por lo general representan abstracciones de: ventanas, paneles, formularios, interfaz de comunicaciones, interfaz de hardware, etc. Clase de Entidad: son aquellos clases que sirven para modelar informacin y comportamiento persistente de fenmenos o conceptos (como ser personas,

V2.0. Ver apunte.

Pgina 1 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

sucesos u objetos del mundo real). Sirven para tener una estructura de datos que depender del sistema. Clase de Control: son aquellos que representan interacciones, transacciones, coordinacin y control entre varios objetos. Modelan comportamiento, lgica de negocio y dinmica del sistema. Es decir, encapsula y asla los cambios de control, interaccin, coordinacin entre objetos. Realizacin de CU de anlisis: es una colaboracin que describe como se lleva a cabo y se ejecuta un CU en trminos de las clases de anlisis. Poseen una descripcin textual del flujo de sucesos que demuestra cmo las clases y los objetos de las mismas interactan para realizar el comportamiento especificado. Consta de: Diagrama de clases de anlisis: una clase de anlisis y sus objetos participan en varias realizaciones de CU por eso se adjuntan diagramas de clases de anlisis a las realizaciones de CU mostrando sus clases y sus relaciones participantes. Diagrama de Interaccin: demuestran como las instancias de las clases de anlisis colaboran e interactan para realizar los comportamientos de CU. Flujo de sucesos-anlisis: los diagramas de realizacin de CU pueden requerir un texto adicional que los explique en trminos de objetos de control. Requisitos especiales: descripciones textuales que recogen todos los requisitos no funcionales sobre una realizacin de CU. Paquete de anlisis: sirven para organizar los artefactos del modelo de anlisis en piezas manejables por lo que puede contener clases de anlisis, realizaciones de CU y otros - Paquete de paquetes. Cada paquete debe ser cohesivo y dbilmente acoplados entre s. servicio. Caractersticas: Representan separacin de intereses de anlisis. Deben crearse basndose en los requisitos funcionales y en el dominio del problema Se pueden convertir en subsistemas. Descripcin de la arquitectura: contiene una vista de la arquitectura del modelo de anlisis y sus artefactos significativos para la arquitectura, tales como: Paquetes de anlisis y sus dependencias. Clases fundamentales del anlisis que son generales, centrales y que tienen muchas relaciones con otras clases de anlisis. Realizaciones de CU que describen funcionalidad importante y crtica. 1.1.3 Trabajadores del Anlisis: Arquitecto: es responsable de la integridad y arquitectura del modelo de anlisis. Siendo NO responsable del desarrollo y mantenimiento de los artefactos del modelo de anlisis. Ingeniero de CU: es responsable de la integridad de las realizaciones de CU garantizando que estos cumplen los requisitos que recaen sobre ellos. NO es responsable de las clases de anlisis ni de las relaciones entre ellas. Ingeniero de Componentes: define y mantiene las responsabilidades, atributos, relaciones y requisitos especiales de las clases de anlisis. Mantiene la integridad de los paquetes (garantizando contenidos correctos y dependencias de otros paquetes correctas y mnimas). 1.1.4 Actividades del Anlisis Anlisis de la arquitectura: su propsito es esbozar el modelo de anlisis y la arquitectura mediante la identificacin de paquetes de anlisis, clases de anlisis y requisitos especiales comunes. Identificacin de paquetes de anlisis: una forma de identificarlos es asignar la mayor parte de un cierto nmero de CU a un paquete segn alguno de los siguientes criterios : o CU para dar soporte a un determinado proceso de negocio. o CU para dar soporte a un actor del sistema o CU que estn relacionados mediante relaciones de generalizacin y de extensin. Identificacin de clases de entidad obvias: la mayora de las clases se identificaran al crear las realizaciones de CU. V2.0. Ver apunte.
Pgina 2 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

Identificacin de requisitos especiales comunes: es un requisito que aparece durante el anlisis; a medida que se exploran las realizaciones de CU y las clases de anlisis. El arquitecto es el responsable de identificarlos. Analizar un CU: Identificar las clases de anlisis: se identifican las clases de anlisis para realizar los CU y determinamos sus nombres, atributos y responsabilidades. Para identificarlas puede ser necesario refinar las descripciones de los CU. Descripcin de interacciones entre los objetos del anlisis: descubrir como interactan los objetos de las clases de anlisis mediante diagramas de interaccin. Puede ser til un diagrama para cada flujo (escenario) de CU. Captura de requisitos especiales: se identifican los requisitos no funcionales de las realizaciones de CU. Analizar una clase: para Identificar las responsabilidades: se puede obtener recopilando los roles que cumple en diferentes realizaciones de CU. Identificar los atributos: un atributo especifica una propiedad de una clase de anlisis necesaria para la responsabilidad de una clase. Identificar asociaciones y agregaciones: los objetos interactan unos con otros mediante enlaces en los diagramas de interaccin, estos enlaces suelen ser instancias de asociaciones entre sus clases. Debindose determinar cuales son las necesarias y tratando de minimizar el nmero de relaciones entre las clases. Identificar generalizaciones: las generalizaciones deben utilizarse para extraer comportamiento compartido entre las clases de anlisis. (Ms fcil de comprender). Capturar requisitos especiales: se identifican requisitos de una clase de anlisis que se identifican en el anlisis pero deben tratarse en el diseo e implementacin. Analizar un paquete: con el fin de que sea independiente de otros paquetes, que cumpla con su objetivo y describir las dependencias de otros. Normas para analizar un paquete: Definir y mantener las dependencias del paquete con otros paquetes cuyas clases contenidas estn asociadas con l. Asegurar que el paquete contiene las clases correctas. Hacer cohesivo el paquete incluyendo en l, solo los objetos relacionados funcionalmente. Limitar las dependencias con otros paquetes. 1.2 Modelado del Comportamiento en el Anlisis 1.3 Patrones de Principios generales para asignar responsabilidades (GRASP) GRASP: Patrones de Principios Generales para Asignar Responsabilidades. La asignacin de responsabilidades es muy importante en el diseo de objetos. La asignacin de responsabilidades tiene lugar durante la creacin de diagramas de interaccin. (y en la programacin) Los patrones son pares problemas/solucin con un nombre que codifican buenos consejos. Qu son los patrones GRASP?: Describen los principios fundamentales del diseo de objetos y la asignacin de responsabilidades, expresados como patrones. Los primero 5 patrones se refieren a cuestiones bsicas, comunes y a aspectos fundamentales del diseo. Estos son los siguientes: Experto en Informacin: o Problema: cul es el principio general para asignar responsabilidades a los objetos? o Solucin: Asignar la responsabilidad a la clase que tiene la informacin necesaria para realizar la responsabilidad. Creador: o Problema: quin debera ser el responsable de la creacin de una nueva instancia de alguna clase? o Solucin: Asignar a la clase B la responsabilidad de crear una instancia de clase A si se cumple uno o ms de los siguientes casos: B agrega objetos de A B contiene objetos de A V2.0. Ver apunte.
Pgina 3 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

B registra instancias de objetos de A B utiliza ms estrechamente objetos de A B tiene los datos de inicializacin que se pasaran a un objeto de A cuando sea creado (donde B es un Experto con respecto a la creacin de A). B es un creador de los objetos de A. Bajo Acoplamiento: o Problema: cmo soportar bajas dependencias, bajo impacto del cambio e incremento de la reutilizacin? o Solucin: Asignar una responsabilidad de manera que el acoplamiento permanezca bajo. Alta Cohesin: o Problema: cmo mantener la complejidad manejable? o Solucin: Asignar una responsabilidad de manera que la cohesin permanezca alta. Controlador: o Problema: quin es el responsable de gestionar un evento de entrada al sistema? o Solucin: Asignar la responsabilidad a una clase que representa una de las siguientes opciones: Representa el sistema global, dispositivo o subsistema. Representa un escenario de CU en que tiene lugar el evento del sistema 1.4 Modelado de la Estructura en el Anlisis 1.5 Introduccin al UML 2.0 UML: es un lenguaje para visualizar, especificar, construir y documentar los artefactos de un sistema orientado a objetos y con gran cantidad de software. Modelo conceptual de UML: comprender el modelo requiere aprender tres elementos. Bloques bsicos de construccin de UML: el vocabulario de UML incluye 3 clases de bloques bsicos. o Elementos: abstracciones que constituyen los ciudadanos de 1ra clase un modelo. Estructurales (clasificadores): son los nombres de los modelos UML. Partes estticas de un modelo y representan cosas materiales o conceptos (Clase, interfaz, colaboracin, CU, nodo, componente, artefacto, clase activa). De comportamiento: son las partes dinmicas de los modelos UML y representan comportamiento en el tiempo y el espacio (interaccin, mquina de estados, actividad) Agrupacin: son las partes organizativas de los modelos de UML (paquete). Anotacin: son las partes explicativas de los modelos UML. Son comentarios para describir, clarificar y hacer observaciones sobre los elementos de un modelo (nota). o Relaciones: ligan a los elementos entre s: Dependencia: relacin semntica entre dos elementos, un cambio en un elemento puede afectarle a la semntica del otro. Asociacin: relacin estructural entre clases que describe un conjunto de enlaces. Generalizacin: relacin de especializacin/generalizacin en la cual el elemento especializado se basa en la especificacin del elemento generalizado. Realizacin: relacin semntica entre clasificadores, un clasificador especifica un contrato que otro clasificador garantiza que cumplir. o Diagramas: agrupan colecciones interesantes de elementos. Son una representacin grfica de un conjunto de elementos, visualizando como un grafo conexo de nodos (elementos) y arcos (relaciones). Se dibujan para V2.0. Ver apunte.
Pgina 4 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

visualizar el sistema desde diferentes perspectivas. Los diagramas se clasifican en 3 grupos: Estructurales: sirven para visualizar, especificar, construir y documentar los aspectos estticos del sistema, estos aspectos representan el esqueleto y la estructura exterior del sistema. Los diagramas de este grupo son: Diagrama de clases: muestran un conjunto de clases, interfaces y colaboraciones y sus relaciones. Abarcan vista - Modelo: abstraccin de diseo esttica de un sistema. simplificada completa y auto Diagrama de componentes: representa la encapsulacin de consistente de la realidad una clase; junto con sus interfaces, puertos y estructura interna. Cubren la vista de implementacin esttica del diseo de un sistema. Diagrama de objetos: representa un conjunto de objetos y - Vista: proyeccin de la sus relaciones. Abarcan la vista de diseo esttica del organizacin y estructura de un modelo del sistema, sistema. centrada en un aspecto del Diagrama de despliegue: muestra una configuracin de mismo nodos de procesamiento en tiempo de ejecucin y los artefactos que residen en ellos. Abordan la vista de despliegue esttica de una arquitectura. Diagrama de paquetes: muestra descomposicin del modelo de unidades organizativas y sus dependencias. De comportamiento: sirven para visualizar, especificar, construir y documentar los aspectos dinmicos de un sistema, estos aspectos representan sus partes mutables. Los diagramas de este grupo son: Diagrama de CU: muestra un conjunto de CU y actores y sus relaciones. Cubren la vista de CU esttica de un sistema. Importantes para modelar y organizar el sistema. Diagrama de Actividad muestra la estructura de un proceso como el flujo de control y datos. Cubre la vista dinmica de un sistema. Diagrama de estado muestra una mquina de estados que consta de estados, transiciones, eventos y actividades. Modela la vida de un nico objeto. De Interaccin: Se utilizan para modelar aspectos dinmicos de los sistemas. Modelan cualquier tipo de interaccin entre instancias, donde una interaccin consta de un conjunto de objetos y sus relaciones, incluyendo los mensajes que se pueden enviar entre ellos. Los diagramas de este grupo son: Diagrama de tiempos: muestra los tiempos reales de una interaccin entre diferentes objetos o roles en posicin a la simple secuencia relativa de mensajes. Diagrama de visin global de interacciones: es un hibrido entre el diagrama de actividades y el diagrama de secuencia. Muestra lo complejo que se realiza el comportamiento por un conjunto de interacciones sencillas. Diagrama de comunicacin: resalta la organizacin estructural de los objetos (y sus relaciones) o roles que envan o reciben mensajes. Diagrama lgico que modela objetos (instancias). Diagrama de secuencia: resalta la ordenacin temporal de los mensajes entre lneas de vida. Son ms fciles de leer. Diagrama lgico que modela objetos. Reglas de UML: especifican a que debe parecerse un modelo bien formado. (Modelo bien formado: aquel que es semnticamente auto consistente y est en

V2.0. Ver apunte.

Pgina 5 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

armona con todos sus modelos relacionados). Existen reglas sintcticas y semnticas para: o Nombres: como llamar a los elementos, relaciones y diagramas. o Alcance: El contexto que da un significado especfico a un nombre. o Visibilidad: como se puede ver y utilizar esos nombres por otros. o Integridad: como se relacionan apropiada y consistentemente los elementos. o Ejecucin: que significa ejecutar o simular un modelo dinmico. Mecanismos comunes de UML: UML se simplifica mediante la presencia de 4 mecanismos comunes que se aplican consistentemente a travs de todo el lenguaje. o Especificaciones: Detrs de cada elemento de su notacin grfica hay una especificacin que proporciona una explicacin textual de la sintaxis y semntica de dicho elemento. o Adorno: Todos los elementos en la notacin UML parten de su smbolo bsico, al cual pueden aadirse una variedad de adornos especficos de ese smbolo. o Divisiones comunes: Divisin clase-objeto una clase es una abstraccin y un objeto es una manifestacin concreta de esa abstraccin Divisin interfaz-implementacin: una interfaz declara un contrato, y una implementacin representa una realizacin concreta de ese contrato. Divisin tipo-rol: tipo declara una entidad y un rol describe un significado de una entidad. o Mecanismos de extensibilidad: UML es abierto-cerrado ya que permite extender el lenguaje de manera controlada. Los mecanismo de extensin de UML comprenden: Estereotipos: extiende el vocabulario, permitiendo crear nuevos bloques de construccin que deriven de los existentes (especficos a un problema). Valor etiquetado: extiende propiedades de un estereotipo permitiendo aadir nueva informacin en la especificacin del mismo. Restriccin: extiende la semntica de los bloques de construccin permitiendo aadir nuevas reglas o modificar las existentes. Unidad N 2: Diseo en el Proceso Unificado de Desarrollo 2.1. Verificacin y validacin de los Modelos de Requerimientos y Anlisis como entrada al proceso de Diseo. 2.2. El Flujo de Trabajo de Diseo: Introduccin: en el diseo se modela el sistema para darle una forma que soporte los requisitos, incluyendo los no funcionales y restricciones. La entrada principales el modelado de anlisis que proporciona una comprensin detallada de los requisitos y brinda una estructura del sistema. Propsitos de diseo: Lograr una comprensin profunda de los requerimientos no funcionales y restricciones. Crear entrada para las actividades de implementacin. Descomponer los trabajos de implementacin en partes manejables. Capturar las interfaces entre subsistemas. Visualizar y reflexionar sobre el diseo utilizando una notacin comn. Crear abstraccin sin costuras de la implementacin (la implementacin es un refinamiento del diseo que rellena lo existente sin cambiar la estructura) Crear un modelo de diseo. El anlisis crea un modelo lgico que captura la funcionalidad del sistema siendo la finalidad del diseo especificar como se implementar esta funcionalidad; creando un modelo que se pueda implementar. En diseo se deciden los aspectos estratgicos y en consecuencia se crea un modelo de diseo. Hacer nfasis en las interfaces, ya que las interfaces entre los subsistemas de diseo son las que mantienen su sistema unido. V2.0. Ver apunte.
Pgina 6 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

Modelo de diseo: Contiene muchos subsistemas de diseo, los subsistemas son componentes que pueden contener diferentes elementos de modelado. Un modelo de diseo consta de: subsistemas de diseo, clases de diseo, interfaces, realizaciones de CU de diseo y diagrama de despliegue. 2.2.1. El Rol del Diseo en el Ciclo de Vida del Software El diseo es la actividad de modelado principal al final de la fase de Elaboracin y el comienzo de las iteraciones de Construccin. Esto contribuye a una arquitectura estable y slida y a crear un plano del modelo de implementacin. 2.2.2. Documentacin de las diferentes etapas: Artefactos de Diseo. Modelo de Diseo: Es un modelo de objetos que describe la realizacin fsica de los CU. Sirve de abstraccin de la implementacin del sistema. Se representa por un sistema de diseo que denota el subsistema de nivel ms alto del modelo. En el diseo los CU son realizados por clases de diseo. Clases de diseo: abstraccin sin costuras de una clase en la implementacin en el siguiente sentido: Se especifica en lenguaje de programacin. Se especifica la visibilidad de los atributos y operaciones. Las relaciones entre las clases tienen una semntica que se corresponde con un significado en el lenguaje de programacin. Los mtodos de una clase de diseo se corresponde directamente con el correspondiente mtodo en la implementacin. Una clase de diseo puede posponer el manejo de algunos requisitos para las subsiguientes actividades de implementacin. Una clase de diseo puede realizar interfaces si tiene sentido hacerlo en el lenguaje de programacin. Una clase de diseo puede activarse (los objetos de la clase mantienen su propio hilo de control y se ejecutan concurrentemente con los otros objetos activos). Realizacin de CU de diseo: Es una colaboracin en el modelo de diseo que describe como se realiza un CU especfico y como se ejecuta en trmino de clases de diseo y sus objetos. Tiene una descripcin de flujo de eventos textual, diagrama de clases que muestran sus clases participantes y diagramas de interaccin que muestran la realizacin de un flujo o escenario concreto de un CU en trmino de interaccin entre los objetos de diseo. Proporciona una realizacin fsica de la realizacin de CU anlisis. Especifican decisiones de implementacin y realiza los requisitos no funcionales. Consta de: Diagrama de clases de diseo: una clase de diseo y sus objetos participan en varias realizaciones de CU, para manejar esto se utiliza un diagrama de clases conectado a una realizacin de CU mostrando sus clases participantes, subsistemas y sus relaciones. Diagrama de interaccin: La secuencia de acciones en un CU comienza cuando un actor invoca el CU mediante el envo de algn tipo de mensaje y llama a otro objeto y as los objetos implicados interactan para realizar y llevar a cabo el CU. Flujo de sucesos-diseo: descripcin textual que explica y complementa los diagramas y a sus etiquetas (marcas de tiempo o descripcin de acciones durante una activacin). Requerimientos de la implementacin: descripcin textual que recoge requisitos tales como los requisitos no funcionales sobre una realizacin de CU que es mejor tratar en la implementacin. Subsistema de diseo:

V2.0. Ver apunte.

Pgina 7 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

Es una forma de organizar los artefactos del modelo de diseo en piezas ms manejables. Puede constar de clases de diseo, realizaciones de CU, interfaces y otros subsistemas. Deber ser cohesivo y dbilmente acoplados. Puede proporcionar interfaces que representan la funcionalidad que exportan en trminos de operaciones. Caractersticas: o Pueden representar una separacin de aspectos de diseo. o Pueden representar componentes que proporcionan varias interfaces compuestos a partir de otros varios componentes de grano ms fino. o Pueden representar productos de software reutilizados que han sido encapsulado en ellos. Interfaz: Se utilizan para especificar las operaciones que proporcionan las clases y los subsistemas de diseo. Una clase de diseo que proporcione una interfaz debe proporcionar tambin mtodos que realicen las operaciones de la interfaz. Un subsistema que proporcione una interfaz debe contener tambin clases de diseo u otros subsistemas que proporcionen la interfaz. Constituyen una forma de separar la especificacin de la funcionalidad en trminos de operaciones de sus implementaciones en trmino de mtodos. La mayora de las interfaces entre subsistemas definen las interacciones permitidas entre los subsistemas. (Se consideran relevante para la arquitectura). El conjunto de interfaces realizadas por un clasificador se conoce como sus interfaces proporcionadas. Cuando un clasificador requiere una o ms interfaces para su operacin, stas se conocen como interfaces requeridas. Descripcin de la arquitectura: vista del modelo de diseo: muestra sus artefactos relevantes para la arquitectura. Considerndose significativo para la arquitectura los siguientes artefactos del modelo de diseo: Descomposicin del modelo de diseo en subsistemas, sus interfaces y las dependencias entre ellos. Clases de diseo fundamentales: clases que poseen traza con clases de anlisis significativas, clases de diseo generales y centrales que tengan muchas relaciones con otras clases de diseo. Realizaciones de CU de diseo que describen funcionalidad importante y crtica que debe desarrollarse pronto; que impliquen muchas clases de diseo. Modelo de Despliegue: Es un modelo de objetos que describe la distribucin fsica del sistema en trmino de cmo se distribuye la funcionalidad entre los nodos de cmputo. Se utiliza como entrada fundamental en las actividades de diseo e implementacin debido a que la distribucin del sistema tiene una influencia principal en su diseo. Cada nodo representa un recurso de cmputo, normalmente un procesador o un dispositivo de hardware similar. Los nodos poseen relaciones que representan medio de comunicacin entre ellos. Puede describir diferentes configuraciones de red, incluidas las configuraciones para prueba y para simulacin. La funcionalidad de un nodo se define por los componentes que se distribuyen sobre ese nodo. Representa una correspondencia entre la arquitectura de software y la arquitectura del sistema. Descripcin de la Arquitectura: Vista del modelo de despliegue: muestra sus artefactos relevantes para la arquitectura. Dada su importancia deberan mostrarse todos los aspectos del modelo de despliegue. 2.2.3. Trabajadores del Diseo. V2.0. Ver apunte.
Pgina 8 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

Arquitecto: es responsable de la arquitectura e integridad de los modelos de diseo y despliegue; garantizando que los modelos son correctos, consistentes y legibles en su totalidad. (Son correctos cuando realizan la funcionalidad descrita en el modelo de CU) Ingeniero de CU: es responsable de la integridad de una o ms realizaciones de CU-diseo y debe garantizar que cumplen los requisitos que se esperan de ellos. Ingeniero de Componentes: define y mantiene las operaciones, mtodos, atributos, relaciones y requisitos de implementacin de una o ms clases de diseo, garantizando que clase del diseo cumple los requisitos que se esperan de ella segn las realizaciones de CU en las que participa. El ingeniero de componentes puede mantener tambin la integridad de uno o ms subsistemas. 2.2.4. Actividades del Diseo. Diseo de la arquitectura: el objetivo de esta actividad es esbozar los modelos de diseo y despliegue y su arquitectura mediante la identificacin de los siguientes elementos: Nodos y sus configuraciones de red: las configuraciones fsicas de red, tienen gran influencia en la arquitectura del software (incluyendo clases activas y distribucin de la funcionalidad entre nodos de la red). Subsistemas y sus interfaces: los subsistemas son un medio para organizar el modelo de diseo en partes manejables que se pueden identificar al principio como forma de dividir el trabajo o bien a medida que el modelo de diseo evoluciona y crece y se convierte en una gran estructura que debe ser descompuesta. Si se hizo durante el anlisis una descomposicin adecuada en paquetes de anlisis, podemos utilizar esos paquetes tanto como sea posible e identificar los correspondientes subsistemas dentro del modelo de diseo; pudiendo ser necesario un refinamiento de esta descomposicin inicial en subsistemas, obtenido de los paquetes de anlisis del modelo de anlisis. Cuando se compra middleware y software del sistema es recomendable considerar cada producto de software comprado como si fuese un subsistema independiente con interfaces explcitas para el resto de los sistemas. Identificacin de interfaces entre subsistemas: las interfaces proporcionadas por un subsistema definen operaciones que son accesibles desde afuera del subsistema. Estas interfaces las proporcionan o bien clases o bien otros subsistemas dentro del subsistema, se comienza considerando las dependencias entre subsistemas ya identificadas. Si un subsistema tiene una dependencia que apunta hacia l, es probable que deba proporcionar una interfaz. Clases de diseo (clases activas): relevante para la arquitectura: se identifican al disear las clases dentro de la actividad de diseo de clases y se refinan de acuerdo a los resultados obtenidos en la actividad de diseo de CU por lo que es suficiente un esbozo inicial de las clases significativas para la arquitectura en esta etapa. Una manera de identificarlas es a partir de las clases de anlisis significativas para la arquitectura. Mecanismos genricos de diseo: se estudian los requisitos comunes, como los requisitos especiales (persistencia, distribucin, caractersticas de seguridad, etc.) identificados en el anlisis en realizaciones de CU-anlisis y en las clases de anlisis y se deciden como tratarlos. El resultado es un conjunto de mecanismos genricos de diseo que pueden manifestarse como clases, colaboraciones o incluso subsistemas. Diseo de un CU: los objetivos del diseo de CU son: Identificar las clases de diseo y/o subsistemas cuyas instancias son necesarias para llevar a cabo el flujo de sucesos del CU. Distribuir el comportamiento del CU entre los objetos del diseo que interactan y/o entre los subsistemas participantes, para lo cual se realiza una descripcin de las interacciones entre objetos de diseo; cuando se tiene un esquema de las clases de diseo necesarias para realizar un CU se debe describir cmo interactan sus correspondientes objetos del diseo. (mediante diagrama de secuencia)

V2.0. Ver apunte.

Pgina 9 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

Identificacin de subsistemas e interfaces participantes: en algunos casos es ms apropiado disear un CU en trminos de los subsistemas y/o interfaces que participan en l. Descripcin de interacciones entre subsistemas: cuando se tiene un esbozo de los subsistemas necesarios para la realizar el CU, debemos describir cmo interactan los objetos de las clases que contiene en el nivel de subsistemas. (Se hace mediante diagrama de secuencia) Captura de Requisitos de Implementacin: se incluyen en las realizaciones de CU todos los requisitos identificados durante el diseo que deberan tratarse en la implementacin, como los requisitos no funcionales. Diseo de una clase: el propsito es crear una clase de diseo que cumpla su papel en las realizaciones de CU y los requisitos no funcionales que se aplican a estos. Para lo cual se realiza lo siguiente: Esbozar la clase de diseo: cuando se toma una interfaz como entrada es simple y directo asignar a una clase de diseo para que proporcione esa interfaz. Pero cuando como entrada se tiene una o varias clases de anlisis los mtodos utilizados dependen del estereotipo de la clase de anlisis. Identificar operaciones: se identifican las operaciones que la clase de diseo va a necesitar y describimos esas operaciones utilizando la sintaxis de los lenguajes de programacin. Como entradas importantes se encuentra: o Las responsabilidades de cualquier clase de anlisis que tenga una traza con la clase de diseo. o Requisitos especiales de cualquier clase de anlisis que tenga una traza con la clase de diseo. o Las interfaces que la clase de diseo necesita proporcionar o Las realizaciones de CU-diseo en los que la clase participa. Identificar atributos: se identifican los atributos requeridos por la clase de diseo y los describimos utilizando la sintaxis del lenguaje de programacin. Un atributo especifica una propiedad de una clase de diseo y es requerido por las operaciones de la clase. Identificar asociaciones y agregaciones: los objetos interactan unos con otros en los diagramas de secuencia. Estas interacciones a menudo requieren asociaciones entre las clases correspondientes. Las instancias de asociaciones deben ser utilizadas para abarcar las referencias con otros objetos, y para agrupar objetos con el propsito de enviarles mensajes. Identificar generalizaciones: las generalizaciones deben ser utilizadas con la misma semntica definida en el lenguaje de programacin. Describir los mtodos: los mtodos pueden ser utilizados durante el diseo para especificar cmo se deben realizar las operaciones. Describir estados: algunos objetos del diseo son estados controlados, lo que significa que sus estados determinan su comportamiento cuando recibe un mensaje. Tratar requisitos especiales: en esta fase debe ser tratado cualquier requisito que no haya sido considerado en pasos anteriores. Diseo de subsistemas: los objetivos del diseo de un subsistema son: Garantizar que el subsistema sea tan independiente como sea posible de otros subsistemas y/o de sus interfaces; es decir se realiza un mantenimiento de las dependencias entre los subsistemas. Garantizar que el subsistema proporciona las interfaces correctas, para lo que se realiza el mantenimiento de interfaces proporcionadas por el subsistema. Las operaciones definidas por las interfaces que proporciona un subsistema deben soportar todos los roles que cumple el subsistema en las diferentes realizaciones de CU. Garantizar que el subsistema cumple su propsito de ofrecer una realizacin correcta de las operaciones tal y como se definen en las interfaces que proporciona por lo cual se realiza el mantenimiento de los contenidos de los subsistemas. V2.0. Ver apunte.
Pgina 10 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

2.3. Estrategias de Prototipado y de Ensamblaje de Componentes. Un prototipo es una versin inicial de un sistema de software que se utiliza para demostrar los conceptos, probar las opciones de diseo y enterarse ms acerca del problema y sus posibles soluciones. La construccin de prototipos reduce el nmero de problemas con la especificacin de requerimientos. Construccin de prototipos en el proceso de software: Existen dos enfoques: Enfoque de construccin de prototipos evolutivos: proporcionan al usuario un sistema incompleto que luego se modifica y aumenta en el momento en que los requerimientos del usuario sean claros y finalmente se convierte en el sistema requerido. No existe una especificacin detallada de este y en muchos casos no existe un documento formal de requerimientos. Enfoque de construccin de prototipos desechables: sirven para ayudar al anlisis y validacin de requerimientos, es decir, ayudan a refinar y clarificar la especificacin del sistema. Tienen un perodo de vida corto, por lo que a la larga no requiere mantenimiento. Tcnica de construccin rpida de prototipos: existen tres tcnicas prcticas de desarrollo que hacen nfasis en la velocidad de entrega: Desarrollo de lenguajes dinmicos de alto nivel: estos lenguajes de programacin que incluyen poderosos recursos de administracin de datos en tiempo de ejecucin. Estos simplifican el desarrollo del programa debido a que reducen muchos problemas de administracin y asignacin de almacenamiento. Los lenguajes dinmicos de alto nivel se pueden combinar para crear el prototipo del sistema. Se puede utilizar diferentes lenguajes para programar diversas partes del sistema, y se puede establecer un marco de comunicacin entre las partes. Donde se puede elegir el lenguaje ms apropiado para una parte lgica de la aplicacin y as acelerar el desarrollo del prototipo. Programacin de Base de datos: dicha programacin se lleva a cabo utilizando un lenguaje especializado que contiene conocimiento de la base de datos y que incluye las operaciones necesarias para la manipulacin de la misma. Ensamblaje de componentes y aplicaciones: es posible reducir el tiempo requerido para desarrollar un sistema, si muchas partes de este se pueden reutilizar ms que disear e implementar. Puede construir los prototipos rpidamente si tiene un conjunto de componentes reutilizables y algunos mecanismos para construir estos componentes en sistemas. El mecanismo de composicin debe incluir recursos de control y mecanismos para la comunicacin de los componentes. El desarrollo de prototipos con reutilizacin comprende dos niveles: el nivel de aplicacin, en el que la aplicacin completa se integra con el prototipo de manera que su funcionalidad pueda ser compartida y el nivel de componente, en el que los componentes individuales se integran dentro de un marco de trabajo estndar para implementar el sistema. Construccin de prototipos de la interfaz de usuario: las interfaces grficas de usuario se han convertido en la norma para los sistemas interactivos. El esfuerzo comprendido en la especificacin, el diseo y la implementacin de una interfaz de usuario representa una parte significativa de los costos de desarrollo de la aplicacin. La construccin de prototipos evolutivos con la participacin del usuario final es la nica forma sensible para desarrollar interfaces grficas de usuario para los sistemas de software. 2.4. Diseo de la Estructura del Software 2.5. Diseo del Comportamiento del Software 2.6. Introduccin a los patrones. 2.6.1. Concepto de patrn. Cada patrn describe un problema que ocurre una y otra vez en un entorno, as como la solucin a ese problema. Los patrones de diseo son descripciones de clases y objetos relacionados que estn particularizados para resolver un problema de diseo general en un determinado contexto, estos hacen que los diseos orientados a objetos sean ms flexibles, elegantes y V2.0. Ver apunte.
Pgina 11 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

reutilizables. Cada patrn nomina, explica y evala un diseo importante y recurrente en sistemas orientados a objetos. Los patrones hacen que sea ms fcil reutilizar buenos diseos y arquitecturas y pueden mejorar la documentacin y el mantenimiento de los sistemas existentes. 2.6.2. Estructura de los patrones. Los patrones tienen 4 elementos esenciales: Nombre: permite describir en pocas palabras un problema de diseo con sus soluciones y consecuencias. Problema: describe cuando aplicar el patrn. Explica el patrn y su contexto. Puede describir problemas concretos de diseo as como tambin las estructuras de clases u objetos que son sintomticas de un diseo inflexible. Condiciones que deben darse para que tenga sentido aplicar el patrn. Solucin: describe los elementos que constituyen el diseo, sus relaciones, responsabilidades y colaboraciones. Consecuencia: las ventajas y desventajas de aplicar el patrn. Los patrones se describen a travs de plantillas que facilitan el aprendizaje, uso y comparacin de los mismos. Estas plantillas estarn divididas en secciones, las cuales pueden ser: - Nombre de patrn y clasificacin - Propsito - Alias - Motivacin - Aplicabilidad - Estructura - Participantes - Colaboraciones - Consecuencias - Implementacin - Cdigo de ejemplo - Usos conocidos - Patrones relacionados 2.6.3. Ventajas en el uso de los patrones Cmo resuelven los patrones los problemas de diseo: Encontrar los objetos apropiados Lo ms complicado del diseo orientado a objetos es descomponer un sistema en objetos. Una de las maneras es modelar el mundo real y traducir al diseo las clases encontradas durante el anlisis. Muchos objetos del diseo proceden del modelo de anlisis. Pero los diseos orientados a objetos suelen acabar teniendo clases que no tienen su equivalente en el mundo real. Estas clases que surgen durante el diseo son fundamentales para lograr un diseo flexible. Los patrones ayudan a encontrar abstracciones menos obvias. Determinar la granularidad de los objetos. Los objetos pueden variar enormemente en tamao y nmero. Los patrones de diseo se encargan de esta cuestin: describiendo representaciones completas de subsistemas como un objeto, formas de descomponer un objeto en otros ms pequeos, producen objetos cuya nica responsabilidad es crear otros objetos, etc. Especificar las interfaces La signatura es el nombre de una operacin declarada por un objeto, ms los parmetros que recibe y el valor de retorno de la misma; esto se lo conoce como signatura. El conjunto de signaturas definidas por las operaciones de un objeto se la denomina interfaz. Las interfaces son fundamentales en los sistemas orientados a objetos. Los objetos solo se conocen a travs de su interfaz. Las interfaces no dicen nada acerca de su implementacin. (Dos objetos pueden tener idnticas interfaces e implementaciones diferentes). Los patrones de diseo ayudan a definir interfaces identificando sus elementos claves y los tipos de datos que se envan a la interfaz. Y tambin especifican relaciones entre interfaces. V2.0. Ver apunte.
Pgina 12 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

Especificar las implementaciones de los objetos La implementacin de un objeto queda definida por su clase, la clase especifica los datos, la representacin interna del objeto y define las operaciones que puede realizar. Las clases se pueden definir en trminos de las existentes. -Herencia de clases frente a herencia de interfaces. Clase: define estado interno del objeto y la implementacin de sus operaciones. (Una clase define el tipo del objeto) Tipo: interfaz del objeto (conjunto de peticiones a los que puede responder) Herencias: De clase: define la implementacin de un objeto en trminos de la implementacin de otro objeto. Mecanismo para extender la funcionalidad de una aplicacin reutilizando la funcionalidad de las clases padres. De interfaces: describe cuando se puede usar un objeto en lugar de otro. -Programar para interfaces, no para una implementacin. Ventajas de manipular objetos en trminos de la interfaz definida por la clase abstracta: Los clientes no tienen que conocer los tipos especficos de los objetos que usan. Los clientes desconocen las clases que implementan dichos objetos (solo conocen las clases abstractas que definen la interfaz) Esto reduce las dependencias de implementacin entre subsistemas. Es decir, no se deben declarar las variables como instancias de las clases concretas. En vez de eso, se ajustarn simplemente a la interfaz definida por una clase abstracta. Facilitar la reutilizacin -Herencia frente a composicin. La herencia de clase y la composicin de objetos son tcnicas para reutilizar funcionalidad. Herencia Composicin La reutilizacin mediante herencia se Es una alternativa a la herencia. La denomina reutilizacin de caja blanca; nueva funcionalidad se obtiene se refiere a la visibilidad: las componiendo objetos para obtener interioridades de las clases padres se funcionalidad ms compleja. hacen visibles a las subclases. Este estilo de reutilizacin se denomina reutilizacin de caja negra porque los detalles internos de los objetos no son visibles. Ventajas e inconvenientes - Se define estticamente en tiempo de - Se define dinmicamente en tiempo de ejecucin. ejecucin. - Fcil de usar. - Requiere de objetos con interfaces - Fcil de modificar la implementacin bien diseadas, dado que a los objetos que est siendo reutilizada. solo se accede por sus interfaces, no se No se puede cambiar la rompe el encapsulamiento. implementacin en tiempo de ejecucin. - Los objetos se pueden reemplazar en - Rompe el encapsulamiento. tiempo de ejecucin siempre que sean - Los cambios en la implementacin del del mismo tipo. padre obligan a cambios en la - Las dependencias de implementacin implementacin de las subclases. son menores. - En un diseo as el comportamiento del sistema depende de las relaciones en lugar de estar definido en las clases. -Delegacin. Es un modo de lograr que la composicin sea tan potente para la reutilizacin como lo es la herencia; lo cual logra a travs de dos objetos que estn encargados de tratar una peticin: un receptor delega operaciones en su delegado.

V2.0. Ver apunte.

Pgina 13 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

Ventaja: hace que sea fcil de combinar comportamientos en tiempo de ejecucin y cambiar la manera en que stos se combinan. Inconveniente: si bien hacen el software ms flexible mediante la composicin de objetos el software dinmico y altamente parametrizado es ms difcil de entender que el esttico 2.7. Patrones de Diseo. 2.7.1. Patrones de creacin. Encapsulan que clases concretas usa el sistema y como se crean y asocian las instancias de esas clases. El sistema conoce las interfaces de los objetos tal y como las definen sus clases abstractas. Dan flexibilidad en que se crea, quien las crea, como la crea y cuando la crea. Ayudan a hacer un sistema independiente de cmo se crean, componen y representan sus objetos. Los patrones de creacin son: Abstract Factory Factory Method Singleton Builder Prototype 2.7.2. Patrones estructurales. Determinan como combinar objetos y clases para definir estructuras complejas. - Establecer comunicacin entre dos clases que naturalmente no se conocen. - Aadir funcionalidad a objetos que naturalmente no la tienen. Los patrones estructurales son: Bridge Composite Facade Adapter Decorator Flyweight Proxy 2.7.3. Patrones de comportamiento. Se ocupan de algoritmos y reparto de responsabilidades. Describen los patrones de comunicacin entre objetos y clases. Se pueden definir abstracciones de algoritmos. Cooperaciones entre los objetos para realizar tareas complejas, reduciendo las dependencias entre los objetos. Asociar comportamiento a objetos e invocar su ejecucin. Los patrones de comportamiento son: Iterator Memento Observer State Strategy Template method Chain of responsability Command Interpreter Mediator Visitor 2.8. Mapeo de estructuras de clases a bases de datos relacionales. Patrones de Persistencia Introduccin: la persistencia significa que los objetos se copian desde una memoria primaria rpida y voltil con la capacidad limitada a una memoria secundaria lenta y persistente. Dado que los objetos de entidad tpicamente retienen informacin que sobrevive los casos

V2.0. Ver apunte.

Pgina 14 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

de uso, los objetos de entidad son candidatos importantes para el almacenamiento persistente. Problemas: en una base de datos relacional, la informacin se almacena en tablas lo cual es problemtico si lo que se quiere es almacenar objetos, por lo que es necesario trasformar la estructura de informacin de objeto a una estructura orientada a tablas; a este problema se lo denomina problema de impedancia. Los principales problemas son tres: se pueden almacenar los datos y no el comportamiento, solo los tipos de datos primitivos pueden almacenarse y no las estructuras complejas de los objetos y el tercer problema es como expresar la herencia en la base de datos. Objetos en tablas: una clase se mapea en tabla de la siguiente manera: a) Se asigna una tabla para la clase b) Cada atributo primitivo se trasforma en una columna de la tabla c) Definir la columna que ser clave primaria. d) Cada instancia de la clase queda representada por una fila de esa tabla e) Mapear las relaciones. Al mapear las relaciones puede que aparezcan nuevas tablas. Se mapea la asociacin y la herencia. Se debe tener en cuenta la multiplicidad. Problemas la mapear la herencia: los objetos que deben ser persistentes deben ser mapeados; pero si las clases se heredan unas con otras, hay tres formas de resolverlo. Eliminacin de la herencia (eliminando el padre): los atributos heredados se copian a todas las tablas que representan las clases descendientes. Simulacin de la herencia: la clase abstracta est en su propia tabla, a la que las tablas descendientes hacen referencia. Eliminacin de la herencia (eliminando el hijo): la clase abstracta est en su propia tabla y los atributos de las clases descendientes se copian (agregan) en dicha tabla. (Es la menos recomendable) Qu clase tiene la responsabilidad de mapear la Base de Datos?: Existen dos procesos utilizados para mapear una base de datos: Proceso de materializacin: transformar una fila en objeto. Proceso de desmaterializacin: transformar un objeto en fila. Qu clase tiene la responsabilidad de materializar y desmaterializar?: Existen dos posturas: Super Objeto Persistente: consta de una clase ObjetoPersistente que brinda servicios de materializacin y desmaterializacin. Los problemas de esta postura son: o Rompe la cohesin funcional de las clases al agregar a las clases de dominio comportamiento de materializarse y desmaterializarse. o Al heredar de la clase ObjetoPersistente, en un lenguaje con herencia simple no podr heredarse de otra clase en caso de ser necesario. Lo cual puede solucionarse utilizando interfaces. Esquema de persistencia: (solucin al problema de la cohesin funcional) Consiste en incorporar una cuarta capa. Se llama principio de control invertido o principio de Hollywood (no nos llame, nosotros lo llamamos). Este principio evita que se pierda la cohesin porque no hay que realizar modificaciones en las clases de dominio. Esta solucin es ms laboriosa (se ampla la estructura, tiempo y costo), porque se agrega una clase por cada clase que se desea sea persistente. Si se cambia una clase de dominio, se debe cambiar la clase correspondiente en el esquema de persistencia. 2.9. Diseo de Interfaces de Usuario. Criterios para el buen diseo GUI: Control del usuario: la tarea del diseador de aplicaciones de negocio es frecuentemente restringir a donde no puede ir el usuario en cualquier momento dado. El usuario debe tener control, pero no a tal grado que pueda hacer un desastre total de datos empresariales. Sensibilidad: si la aplicacin est procesando durante mucho tiempo, considere la adicin de una escala deslizante para indicar el porcentaje del trabajo que se ha realizado, o con algn mensaje informativo en la barra de estado. Se usan los V2.0. Ver apunte.
Pgina 15 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

cuadros de mensajes para interrumpir al usuario e informarle que se ha detectado un error. Personalizacin: no todos los usuarios tienen las mismas necesidades, y el programador puede dejar muchas de las tareas de personalizacin a los usuarios. Direccin: el concepto direccin es muy bien soportado por el paradigma objetoaccin. Es ms intuitivo localizar el objeto que se desea y manipularlo directamente que el emitir un comando crptico y declarar el objeto al cual se aplica el comando. Consistencia: la aplicacin debe ser consistente con el mundo en el que los usuarios viven y trabajan diariamente, se debe lograr consistencia en los rtulos de los datos a lo largo de la aplicacin para lo cual el proyecto debe tener un conjunto de nombre de rtulos estndar para cada atributo del modelo de informacin. Las aplicaciones deben ser funcionalmente consistentes dentro de la aplicacin, esto se logra mediante el apego a estndares para el aspecto y sensacin, nombres de mens, etc. Las aplicaciones tambin debern ser consistentes con el aspecto, sensacin y lenguaje de otras aplicaciones. Claridad: la informacin que se presenta en la interfaz debe ser inmediatamente comprensible, y el uso de la aplicacin debe ser visualmente evidente. Esttica: la composicin y disposicin de una ventana debe ser visualmente agradable. Deber atraer la vista hacia la informacin que es ms importante. El color debe usarse de manera econmica y sensata, reservando los iconos para las reas en donde realmente se necesitan pistas visuales. Indulgencia: un buen diseo de interfaz debe motivar la exploracin. El usuario debe sentirse libre para explorar por la aplicacin y dar vistazos rpidos en las diversas ventanas y caractersticas. Conciencia de las fortalezas y limitaciones humanas: las computadoras estn diseadas para ser usadas por gente real, y siendo personas todos tenemos limitaciones. Es mucho ms fcil reconocer una pista visual o comando que el memorizar cmo se debe teclear. En una interfaz grfica de usuario cada comando o accin posible debe estar disponible ante el usuario por medio de un botn, elemento de men o icono. Cohesin de ventanas: los mdulos que ejecutan una idea altamente cohesiva tienden a ser ms fciles de comprender y ms baratos de mantener a lo largo del tiempo. La alta cohesin y bajo acoplamiento llegaron a ser la meta para los mdulos bien diseados. Los niveles de cohesin en orden aproximado desde el ms deseable al menos deseable son: Funcional: una ventana o conjunto de ventanas funcionalmente cohesivas manejan un evento a nivel negocio. La ventaja de las ventanas funcionalmente cohesivas es que se tienen ventanas eficientes y especializadas que son menos complejas, ms fcil de usar. (El cdigo interno existe para ejecutar una sola idea, lo que hace que sea ms fcil de comprender y ms fcil de mantener). La desventaja de la cohesin funcional es que frecuentemente incrementa la cantidad de ventanas de la interfaz. Secuencial: una ventana secuencialmente cohesiva es aquella en donde los eventos estn agrupados debido a que suceden en secuencia. El primer evento sucede como predecesor del siguiente, y ese del siguiente y as sucesivamente. La recompensa de la cohesin secuencial es que mapea muy de cerca con el flujo de trabajo manual. La desventaja de este tipo de ventana es que ahora es una mezcla muy compleja de cdigo relacionado. La ventana es mucho ms compleja de usar y mucho ms costosa de mantener. Comunicativa: una ventana comunicativamente cohesiva es aquella en la que los eventos han sido agregados porque afectan al mismo objeto, donde el compartir de los datos es la razn principal para agrupar los eventos. La recompensa es que los eventos comparten el mismo cdigo de acceso de datos y las mismas reglas de negocio basadas en cliente. El problema es que las ventanas frecuentemente sirven a un grupo de usuarios diferentes. Procedural: ventana proceduralmente cohesiva organiza las tareas de acuerdo a la descripcin de trabajo de un usuario particular. Los eventos son agregados para dar al usuario todo lo que necesita en una ventana. V2.0. Ver apunte.
Pgina 16 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

Temporal: sucede cuando los eventos estn agrupados en una ventana simplemente porque suceden al mismo tiempo. Lgica: sucede cuando los eventos estn agrupados para compartir el mismo cdigo. Coincidental: cualquier relacin que aqu se encuentre entre eventos en una ventana coincidentalmente cohesiva existe solamente en la mente del programador que la creo. Diseo de interfaces: el diseo de interfaces externas especifica el aspecto, sensacin y comportamiento de la parte del sistema que ve el usuario, es un refinamiento del prototipo de interfaz. Para qu hacer una especificacin escrita? La especificacin de diseo escrita proporciona un mtodo para documentar y revisar las ideas con los que integran el proyecto que es mucho ms barato que la codificacin. La disposicin, descripcin y diagramas de navegacin de las ventanas son herramientas excelentes para la validacin de la propuesta de diseo con la comunidad de usuarios. Es tambin, una herramienta de administracin, ya que le permite que la aplicacin se divida entre varios programadores para su construccin. Productos del diseo de la interfaz externa: los componentes de un diseo de interfaz externa para una interfaz grfica de usuario incluyen: Panorama del sistema y el panorama de la aplicacin: el panorama del sistema es una descripcin escrita del objeto del negocio y alcances del sistema completo. Incluye una descripcin breve de la necesidad del negocio, los usuarios pretendidos y cmo se acomodar la aplicacin en la estrategia general para satisfacer estas necesidades. Si el sistema es grande y se divide en varias aplicaciones, se deber escribir un panorama de la aplicacin para cada subseccin del sistema que sea implementada como una aplicacin identificable. Diagramacin de navegacin por ventanas: le objetivo de esta iteracin del prototipo es determinar el tipo de ventana correcto y las rutas de navegacin, y definir una unidad de trabajo adecuada para el usuario. Especificacin de ventanas: cada ventana del diagrama de navegacin requiere una especificacin. La especificacin de ventana tiene un pblico tcnico y no tcnico. Los usuarios necesitaran revisar la disposicin de ventanas y sus descripciones. Los programadores utilizaran el documento completo, incluyendo las miniespecificaciones. Los que prueban y los instructores debern ser capaces de obtener el comportamiento deseado de la especificacin y comenzar a escribir sus scripts de prueba y materiales de capacitacin sin tener que esperar el producto final. Hay cuatro partes de una especificacin externa de ventanas: disposicin de ventanas, descripcin de ventanas, miniespecificacin de ventanas y especificacin de campo. Prueba de una interfaz grfica de usuario: una interfaz grfica de usuario es mucho ms difcil del probar que las pantallas tradicionales basadas en caracteres. La especificacin de diseo externo es crucial para quienes hacen las pruebas, le dicen, exactamente la manera en la que se supone debe comportarse el sistema. Le da una base para la escritura de scripts de prueba que se usan para comprobar el comportamiento actual de la aplicacin terminada. Si una especificacin de diseo se puede determinar si la aplicacin es consistente, pero no si es correcta. 2.10. Diseo Arquitectnico Patrones Arquitectnicos. Diseo Arquitectnico Introduccin: los sistemas grandes siempre se descomponen en subsistemas. El proceso de diseo arquitectnico sirve para identificar estos subsistemas y establecer un marco de trabajo para el control y comunicacin de los subsistemas y lo que produce este proceso de diseo es una descripcin de la Arquitectura de Software. El diseo arquitectnico es la primera etapa en el proceso de diseo y representa un vnculo crtico entre el diseo y los procesos de ingeniera de requerimientos. La descomposicin arquitectnica es necesaria para estructurar y organizar la especificacin. El modelo arquitectnico es a menudo el punto inicial para la especificacin de diversas partes del sistema.

V2.0. Ver apunte.

Pgina 17 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

El proceso de diseo arquitectnico comprende el establecimiento de un marco de trabajo estructural bsico para un sistema. Esto implica identificar los componentes principales del sistema y la comunicacin entre ellos. La salida del proceso de diseo arquitectnico es un documento de diseo arquitectnico que consta de representaciones grficas de los modelos de sistemas ms un texto descriptivo asociado. El diseo arquitectnico se basa en un modelo o estilo arquitectnico particular, sin embargo muchos sistemas grandes comprenden ms de un modelo, se dice que la arquitectura del sistema es una arquitectura compuesta que se crea al combinar diferentes modelos. La arquitectura del sistema afecta al desempeo, robustez, distributibilidad y mantenibilidad del sistema. Por lo tanto, el estilo particular y la estructura elegida para una aplicacin puede depender de los requerimientos no funcionales del sistema: Desempeo: si es un requerimiento crtico, sugiere que la arquitectura se debe disear para ubicar las operaciones crticas en un nmero reducido de subsistemas con poca comunicacin. Seguridad: si es un requerimiento crtico, sugiere utilizar una estructura en capas para la arquitectura donde los recursos crticos estn protegidos por las capas ms internas. Proteccin: si es un requerimiento crtico, sugiere que la arquitectura se debe disear para que las operaciones relacionadas con la proteccin se localicen en un solo subsistema. Disponibilidad: si es un requerimiento crtico, sugiere que la arquitectura debe disearse para incluir componentes redundantes. Mantenibilidad: si es un requerimiento crtico, sugiere que la arquitectura debe disearse utilizando componentes autocontenidos. Actividades del Proceso de Diseo Arquitectnico: Estructuracin del sistema: la primera fase de la actividad de diseo arquitectnico se refiere a la descomposicin del sistema en un conjunto de subsistemas. Un diseo arquitectnico se puede ver como un diagrama en bloques en el que cada cuadro representa un subsistema. Un diagrama arquitectnico de bloques representa un panorama general de la estructura del sistema; y es efectivo para la comunicacin con los stakeholders del sistema. Si bien el diagrama de bloques es un modelo de representacin arquitectnica til, se pueden desarrollar modelos ms especficos de la estructura, tres de ellos son: o Modelo de depsito: los subsistemas deben intercambiar informacin para que puedan trabajar de forma conjunta y efectiva. Este modelo es adecuado cuando en las aplicaciones los datos son generados por un subsistema y utilizados por otro. Es decir, cuando se comparten grandes cantidades de datos. Existen dos formas de lograr esto: Todos los datos se ubican en una BD central que puede ser accedida por todos los subsistemas (Modelo depsito). Cada subsistema tiene su propia BD. Los datos se intercambian con otros subsistemas pasando mensajes entre ellos. Ventajas del modelo: Es una forma eficiente de compartir datos en grandes cantidades. Los subsistemas que producen datos no necesitan saber como son utilizados por otros subsistemas. Las actividades como las de backup, seguridad, control de acceso y recuperacin de errores estn centralizadas. Los subsistemas no necesitan saber como se produce la gestin centralizada. El modelo de comparticin es visible a lo largo del esquema de depsito. Desventajas del modelo: Los subsistemas deben estar acordes al modelo de depsito de datos (puede ser difcil o imposible integrar los nuevos subsistemas si sus modelos de datos no se ajustan al esquema acordado) V2.0. Ver apunte.
Pgina 18 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

Varios subsistemas tienen diferentes requerimientos de polticas de seguridad, recuperacin y respaldo. El modelo fuerza a la misma poltica para todos los subsistemas. Es difcil distribuir el depsito en varias mquinas. (Habr problemas con la redundancia e inconsistencia de los datos si se quiere distribuir un depsito centralizado lgicamente). o Modelo Cliente-Servidor: modelo de sistemas distribuido que muestra como los datos y el procesamiento se distribuyen a lo largo de varios procesadores. Los clientes tiene que conocer los nombres de los servidores disponibles y los servicios que suministran pero los servidores no requieren conocer la identidad de los clientes o cuantos clientes existen. Los componentes principales del modelo son: Conjunto de servidores independientes que ofrecen servicios a otros subsistemas. Conjunto de clientes (subsistemas) que llaman a los servicios ofrecidos por los servidores. Una red que permite a los clientes acceder a estos servicios. Ventajas del modelo: es una arquitectura distribuida por lo que los sistemas de red se pueden utilizar de forma efectiva con muchos procesadores distribuidos y es fcil agregar un nuevo servidor e integrarlo con el resto del sistema. Desventajas del modelo: no existe un modelo compartido de datos y los subsistemas por lo general organizan sus datos de diversas formas lo que implica que es difcil anticiparse a los problemas al momento de integrar los datos de un nuevo servidor. Cada servidor debe tener responsabilidad de las actividades de administracin de datos como la de respaldo y recuperacin. o Modelo de mquina abstracta: modela la interaccin (interfaces) entre los subsistemas. Organiza un sistema en una serie de capas, cada una de las cuales suministra un conjunto de servicios. Cada capa define una mquina abstracta cuyo lenguaje de mquina se utiliza para implementar el siguiente nivel de la mquina abstracta. Ventajas: El enfoque en capas permite el desarrollo incremental de sistemas. Esta arquitectura es cambiable y portable: si su interfaz se preserva, una capa se puede reemplazar por otra capa. Cuando las interfaces de las capas cambian, solo afecta a la capa adyacente. Desventajas: Estructurar a los sistemas de esta forma resulta difcil. El desempeo puede ser un problema debido a los mltiples niveles de interpretacin de rdenes que algunas veces se requieren. Modelo de Control: para trabajar como un sistema, los subsistemas deben controlarse para que sus servicios se entreguen al lugar correcto en el momento justo. Para lo que se necesita organizar los subsistemas acorde a un modelo de control. Los modelos de control en el nivel arquitectnico comprenden el nivel de control entre los subsistemas. Dos enfoques para el control: o Control centralizado: un subsistema se designa como controlador del sistema y tiene la responsabilidad de administrar la ejecucin de otros subsistemas. Los modelos de control centralizados se dividen en dos clases, dependiendo si los subsistemas controlados se ejecutan secuencialmente o en paralelo: Modelo de llamada-retorno (secuencial): ste es un modelo familiar de subrutina descendente en el que el control inicia en la parte superior de una jerarqua, y por medio de llamadas a la subrutina, pasa a los niveles inferiores del rbol. Este modelo se utiliza en el nivel de los mdulos para controlar las funciones u objetos. Las subrutinas en un lenguaje de programacin que son llamadas por las otras subrutinas son naturalmente funcionales. La naturaleza rgida y restringida de este modelo es a la vez una fortaleza y una debilidad. Es una fortaleza
Pgina 19 de 32

V2.0. Ver apunte.

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

debido a que es relativamente sencillo analizar los flujos de control y conocer cmo responder el sistema a cierto tipo de entrada y es una debilidad ya que las excepciones a las operaciones normales son tediosas de manejar. Modelo de Administrador (paralelo): ste se aplica a los modelos concurrentes. Un componente de sistema se designa como sistema administrador y controla el inicio, la detencin y la coordinacin de otros procesos del sistema. Un proceso es un subsistema o mdulo que se ejecuta en paralelo a otros procesos. El controlador central administra la ejecucin de un conjunto de procesos decidiendo cuando se deben iniciar o detener los mismos. o Control basado en eventos: cada subsistema puede responder a eventos generados en el exterior. Estos eventos pueden provenir de otros subsistemas o del entorno del sistema. En los modelos centralizados las decisiones se determinan por valores de algunas variables de estado de sistema. Un subsistema no necesita tener acceso a la informacin del estado para manejar estos eventos puesto que la informacin del estado por lo general no determina el flujo de control. Existe una variedad de diferentes tipos de sistemas dirigidos por eventos que se pueden desarrollar. A continuacin se desarrollan dos modelos de control: Modelo de transmisin: un evento se transmite a todos los subsistemas. Cualquier subsistema que pueda manejar ese evento responde a l. Estos modelos son efectivos para integrar subsistemas distribuidos a los largo de diferentes computadoras de una red. Los subsistemas registran un inters en eventos especficos. Cuando estos eventos ocurren el control se transfiere al subsistema que puede manejar el evento. Los subsistemas son los que deciden que eventos requieren. La ventaja es que la evolucin es relativamente sencilla; un nuevo subsistema que maneje clases particulares de eventos. La desventaja de este modelo es que los subsistemas no saben si los eventos se manejarn, ni cuando lo harn.(Un subsistema no conoce que otros subsistemas registran inters en el evento) Modelos dirigidos por interrupciones: se utilizan en sistemas de tiempo real donde las interrupciones externas son detectadas por un controlador de interrupciones y pasadas a algn otro componente para su procesamiento. Se utilizan cuando es necesaria la respuesta inmediata de algn evento. Es complejo de programar y difcil de validar. Descomposicin modular: es la etapa de descomponer los subsistemas en mdulos. Por lo general los componentes en los mdulos son ms pequeos que los subsistemas y esto permite utilizar modelos alternativos de descomposicin. Se consideran dos modelos tiles para la descomposicin de subsistemas en mdulos: o Modelo Orientado a Objetos: el sistema se descompone en un conjunto de objetos que se comunican entre ellos; donde los mdulos son objetos con estado privado y con operaciones definidas sobre el estado. El modelo estructura al sistema en un conjunto de objetos dbilmente acoplados con interfaces bien definidas. Los objetos llaman a los servicios ofrecidos por los otros objetos. Ventajas: los objetos estn dbilmente acoplados, la implementacin de objetos se puede modificar sin afectar a los otros objetos, la estructura del sistema es bastante comprensible, los objetos se pueden reutilizar. Desventajas: para utilizar los servicios, los objetos deben hacer referencia explcita al nombre y a la interfaz de otros objetos. Si se quiere cambiar una interfaz para satisfacer los cambios del sistema, se debe evaluar el efecto de ese cambio sobre todos los usuarios del objeto cambiado. o Modelo de Flujo de Datos: el sistema se descompone en mdulos funcionales que afectan entradas de datos y las transforman en datos de salida. Los mdulos son transformaciones funcionales. Las transformaciones funcionales
Pgina 20 de 32

V2.0. Ver apunte.

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

procesan sus entradas y producen sus salidas. Es decir, los datos fluyen a travs de estas transformaciones hasta que se convierten en salidas. Ventajas: permite reutilizacin de transformaciones; es intuitiva puesto que muchas personas visualizan su trabajo en trminos de procesamiento de entradas y salidas; permite que el sistema evolucione al agregar nuevas transformaciones de forma directa; es sencilla de implementar ya sea como un sistema concurrente o uno secuencial. Desventajas: la principal proviene de la necesidad que un formato para transferir datos que sea reconocido por todas las transformaciones con las que se comunica en el formato de los datos a ser procesador, o se debe imponer un formato estndar para todos los datos comunicados. Arquitectura de dominio especfico: los modelos arquitectnicos antes descriptos son modelos generales, y se pueden aplicar a diversas clases de sistemas. Tambin se pueden utilizar modelos arquitectnicos especficos para un dominio de aplicacin particular. Existen dos tipos de modelos arquitectnicos de dominio especfico: Modelos genricos: son abstracciones de varios sistemas reales. Encapsulan las caractersticas principales de estos sistemas. Modelos de Referencia: son modelos abstractos y describen a una clase mayor de sistemas. Por lo general se derivan de un estudio de dominio de aplicacin. Representan la arquitectura ideal que incluye todas las caractersticas que un sistema podra tener. Se utilizan como una base para la implementacin de sistemas. La funcin principal es servir como medio de comparacin de diversos sistemas en un dominio. Un modelo de referencia provee un vocabulario para la comparacin. Arquitectura de sistemas distribuidos: un sistema distribuido es un sistema donde el procesamiento de la informacin es distribuido sobre varias computadoras. A continuacin se tratan 6 caractersticas importantes de los sistemas distribuidos: Comparticin de recursos: permite compartir los recursos de software y hardware asociados a diversas computadoras de una red. Apertura: los sistemas distribuidos son sistemas abiertos que se pueden extender agregndole nuevos recursos no propietarios. Concurrencia: varios procesos operan al mismo tiempo en diferentes computadoras de la red. Escabilidad: las operaciones del sistema se pueden incrementar agregando nuevos recursos para cubrir las demandas de dicho sistema. Tolerancia a fallos: la disponibilidad de varias computadoras y el potencial para replicar informacin significa que los sistemas distribuidos pueden tolerar algunas fallas de hardware y software. Transparencia: esconder al usuario la naturaleza del sistema. Desventajas: Complejidad: son ms complejos que los sistemas centralizados, por lo que es ms difcil probar estos sistemas. Seguridad: el sistema se puede acceder desde varias computadoras diferentes y el trfico sobre la red debe estar sujeto a inspecciones. Manejabilidad: las diversas computadoras de un sistema pueden ser de diferentes tipos o ejecutar diferentes versiones del sistema operativo. Impredecibilidad: los sistemas distribuidos son impredecibles en su respuesta. A continuacin se presentan tres arquitecturas de sistemas distribuidos: Arquitectura multiprocesador: es el modelo ms simple de un sistema distribuido, en el cual, el sistema consiste de varios procesos diferentes que pueden ejecutarse en procesadores diferentes. Estos son comunes entre los sistemas grandes de tiempo real. Estos sistemas recolectan informacin, toman decisiones utilizando esta informacin, y el despus envan seales a los actuadores que modifican el entorno del sistema. El uso de mltiples procesadores mejora el desempeo y elasticidad del sistema. Arquitectura Cliente-Servidor: una aplicacin se modela como un conjunto de servicios proporcionados por los servidores y un conjunto de clientes que utilizan ese V2.0. Ver apunte.
Pgina 21 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

servicio. Los clientes deben saber que servidores estn disponibles, pero por lo general no reconocen la existencia de otros clientes. Los clientes y los servidores son procesos diferentes. El diseo de sistema cliente-servidor debe reflejar la estructura lgica de la aplicacin que se desarrolla. Cuando se disea un sistema distribuido, se debe hacer una clara distincin entre las capas de: presentacin lgica de aplicacin y administracin de datos puesto que de esta forma es posible distribuir cada capa a una computadora diferente. A la arquitectura cliente-servidor ms simple se la denomina arquitectura cliente-servidor de dos capas, la cual se presenta de 2 formas: o Modelo cliente delgado: el procesamiento de la aplicacin y administracin de datos se lleva a cabo en el servidor. o Modelo cliente grueso: el servidor solo es responsable de la administracin de datos. El problema fundamentar con un enfoque cliente-servidor de dos capas es que las 3 capas lgicas deben asociarse a dos sistemas de cmputos. Para evitar estos problemas (escalabilidad y desempeo o de administracin del sistema), un enfoque alternativo es utilizar una arquitectura cliente-servidor de 3 capas, donde las 3 capas lgicas son procesos separados lgicamente; lo cual no implica necesariamente que existan 3 sistemas de cmputos conectados a la red. La arquitectura cliente-servidor de 3 capas y las variantes de mltiples capas que distribuye el procesamiento de la aplicacin sobre varios servidores son inherentemente ms escalables que las arquitecturas de 2 niveles. Arquitecturas de objetos distribuidos: se remueve la distincin ente cliente y servidor y se disea la arquitectura del sistema como una arquitectura de objetos distribuidos. Los componentes fundamentales del sistema son objetos que proveen una interfaz a un conjunto de servicios que ellos suministran. Otros objetos llaman a estos servicios sin ninguna distincin lgica entre cliente y un servidor. Los objetos se distribuyen a lo largo de varias computadoras sobre una red y se comunican a travs de middleware. ste provee un conjunto de servicios que permiten la comunicacin, agregacin y destruccin de los objetos del sistema. Este middleware se denomina un agente de solicitud de objetos. Su papel es proveer una interfaz transparente entre los objetos. Ventajas: o Los objetos proveedores de servicios se pueden ejecutar en cualquier nodo de la red o Permite agregar nuevos recursos si es necesario o El sistema es flexible y escalable o Es posible reconfigurar el sistema de forma dinmica conforme a lo requerido, migrando los objetos a lo largo de la red Esta arquitectura se utiliza de dos formas en el diseo de sistemas: o Como un modelo lgico que permite estructurar y organizar el sistema. o Con un enfoque flexible p/ la implementacin de sistemas cliente-servidor. Patrones Arquitectnicos. N-Tier Client-Server - Separacin de intereses: niveles diferentes claramente divididos para presentacin, negocio y manejo de datos. - Comunicaciones sincrnicas: la comunicacin entre niveles es pedido- respuesta - Distribucin flexible: todos los niveles pueden correr en la misma mquina o en su propia mquina.

V2.0. Ver apunte.

Pgina 22 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

Messaging

- Comunicaciones asincrnicas: los clientes envan pedidos a una cola donde se almacenan hasta que una aplicacin los remueve. El cliente contina sin esperar la respuesta. - Calidad de servicio configurable: la cola es configurable para una entrega de mayor velocidad, etc. - Bajo acoplamiento: no hay vnculos directos entre clientes y servidores.

Publish-Suscribe

- Mensajera muchos a muchos: los mensajes publicados son enviados a todos los suscriptores que estn registrados en el tpico. Muchos suscriptores pueden escuchar en el mismo tpico y muchos publicantes pueden publicar en el mismo tpico. - Calidad de servicio: mecanismos de comunicacin: *mensajes seguros/no seguros; * punto a punto o broadcast. - Bajo acoplamiento: No hay vnculos entre los publicantes y suscriptores.

Broker

- Arquitectura Hub-and-spoke: brker= concentrador de mensajes y los remitentes y receptores se conectan como rayos. - Realizan ruteo de mensajes - Realiza transformacin de mensajes: el brker transforma el tipo de mensaje de origen recibido en el puerto de entrada en el tipo de mensaje destino requerido por el puerto de salida.

Process coordinator

- Encapsulamiento de proceso: el coordinador encapsula la secuencia de pasos necesarios para completar un proceso de negocio. - Bajo acoplamiento: los componentes del servidor son inconscientes de su rol en el proceso de negocio general y el orden de los pasos del proceso - Comunicaciones flexibles: las comunicaciones entre el coordinador y los servicios pueden ser sincrnicas o asincrnicas.

2.11. Validacin y verificacin del Diseo. Unidad N 3: Implementacin en el Proceso Unificado de Desarrollo 3.1. Flujo de Trabajo de Implementacin: 3.1.1. El Rol de la Implementacin en el Ciclo de Vida del Software: Si bien en la fase de Elaboracin se lleva a cabo trabajo de implementacin para crear la lnea base ejecutable de la arquitectura, la implementacin es el centro durante las iteraciones de Construccin y luego en la fase de Transicin para tratar defectos tardos como los encontrados con las distribuciones beta del sistema. 3.1.2. Artefactos de la Implementacin: Modelo de Implementacin: describe cmo son los elementos del modelo de diseo, es decir, cmo las clases se implementan en trminos de componentes. Este modelo describe como se organizan los componentes de acuerdo con los mecanismos de estructuracin y V2.0. Ver apunte.
Pgina 23 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

modularizacin disponibles en el entorno de implementacin y en el (o los) lenguaje de programacin utilizado, y como dependen los componentes unos de otros. Componente: es el empaquetamiento fsico de los elementos de un modelo. Algunos estereotipos estndar son: <<executable>><<file>> <<library>> <<tables>> <<document>> Caractersticas de los componentes: Tienen relaciones de traza con los elementos del modelo que implementan. Un componente puede implementar varios elementos. Stub: es un componente con una implementacin esqueltica o de propsito especial que puede ser utilizada para desarrollar o probar otro componente que depende del stub. Subsistema de implementacin: proporcionan una forma de organizar los artefactos del modelo de implementacin en trozos ms manejables. Un subsistema puede estar formado por componentes, interfaces y otros subsistemas. Un subsistema puede implementar las interfaces que representan la funcionalidad que exportan en forma de operaciones. Los subsistemas de implementacin deberan seguir la traza uno a uno de sus subsistemas de diseo correspondientes. Interfaz: las interfaces pueden ser utilizadas en el modelo de implementacin para especificar las operaciones implementadas por componentes y subsistemas de implementacin. Descripcin de la arquitectura: contiene una visin de la arquitectura del modelo de implementacin, el cual representa sus artefactos significativos arquitectnicamente. Los siguientes artefactos son significativos arquitectnicamente: La descomposicin del modelo de implementacin en subsistemas, sus interfaces y las dependencias entre ellas. Componentes claves: componentes ejecutables, componentes generales, centrales que implementan mecanismos de diseo genricos de los que dependen muchos otros componentes. Plan de integracin de construcciones: es importante construir el software incrementalmente en pasos manejables. El resultado de cada paso es llamado construccin, que es la versin ejecutable de una parte especfica del sistema. Cada construccin es sometida a pruebas de integracin antes de que se cree otra construccin. Beneficios del enfoque incremental: Se puede crear una versin ejecutable del sistema muy pronto. Es ms fcil localizar defectos durante las pruebas de integracin. Las pruebas de integracin son ms minuciosas que las del sistema completo. Cada iteracin resultar en al menos una construccin, sin embargo, la funcionalidad a ser implementada en una iteracin en una sola construccin. (Puede que se cree una secuencia de construcciones dentro de una iteracin). Un plan de integracin de construcciones describe la secuencia de construcciones necesarias en una iteracin. Concretamente describe lo siguiente para cada construccin: La funcionalidad que se espera que sea implementada en dicha construccin. Las partes del modelo de implementacin que estn afectadas por la construccin. 3.1.3. Trabajadores de la Implementacin: Arquitecto: responsable de la integridad y la arquitectura del modelo de implementacin y asegura que el modelo es correcto, completo y legible. Tambin es responsable de la asignacin de componentes ejecutables a nodos. Ingeniero de componentes: define y mantiene el cdigo fuente de uno o varios componentes, garantizando que cada componente implementa la funcionalidad correcta. Es quien mantiene la integridad de uno o varios subsistemas de implementacin, garantizando que los contenidos son correctos, que sus dependencias con otros subsistemas o interfaces son correctas y que implementan correctamente las interfaces que proporcionan. Integrador de sistemas: es responsable de planificar la secuencia de construcciones necesarias para cada iteracin y la integracin de cada construccin cuando sus partes han sido implementadas. 3.1.4. Actividades de la Implementacin: V2.0. Ver apunte.
Pgina 24 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

Implementacin de la arquitectura: el propsito es esbozar el modelo de implementacin y su estructura mediante: Identificacin de los componentes significativos arquitectnicamente. Asignacin de componentes a los nodos en las configuraciones de redes relevantes. Integrar el sistema: los objetivos de la integracin del sistema son: Crear un plan de integracin de construcciones que describa las construcciones necesarias en una iteracin y que los requisitos de cada construccin. Integrar cada construccin antes de que sea sometida a pruebas de integracin. Implementar un subsistema: el propsito es asegurar que un subsistema cumple su papel en cada construccin, tal y como se especifica en el plan de integracin de la construccin. Un subsistema cumple su propsito cuando los requisitos a ser implementados en la construccin actual y aquellos que afectan al subsistema esta implementados correctamente por componentes dentro del subsistema. Implementar una clase: el propsito es implementar una clase de diseo en un componente fichero, esto incluye lo siguiente: Esbozo de un componente fichero que contendr el cdigo fuente. Generacin de cdigo fuente a partir de la clase de diseo y de las relaciones en que participa. Implementacin de las operaciones de la clase de diseo en forma de mtodos Comprobacin de que el componente proporciona las mismas interfaces que la clase de diseo. Realizar prueba de unidad: el propsito es probar los componentes implementados como unidades individuales. Tipos de prueba: Pruebas de especificacin De caja negra Pruebas de estructura De caja blanca 3.2. Mapeo del Diseo a la Implementacin 3.3. Estndares de Programacin 3.4. Mejores Prcticas en la implementacin de software orientado a objetos 4.1. Flujo de Trabajo de Prueba: Introduccin: en este flujo de trabajo se verifica el resultado de la implementacin probando cada construccin. Los objetivos, ms concretamente, de la prueba son: Planificar las pruebas necesarias en cada iteracin. Disear e implementar las pruebas creando los casos de prueba que especifican que probar. Realizar las diferentes pruebas y manejar los resultados de cada prueba sistemticamente. 4.1.1. El rol de la Prueba en el Ciclo del Vida del Software: Inicio: puede hacerse parte de la planificacin inicial de las pruebas cuando se define el mbito del sistema. Elaboracin: se centra en esta fase la realizacin de pruebas, cuando se prueba la lnea base ejecutable de la arquitectura. Construccin: se centra en esta fase la realizacin de pruebas, cuando el grueso del sistema esta implementado. Transicin: el centro se desplaza hacia la correccin de defectos durante los primeros usos y a las pruebas de regresin. 4.1.2. Artefactos de la Prueba: Modelo de Pruebas: Describe principalmente cmo se prueban los componentes ejecutables en el modelo de implementacin con pruebas de integracin y de sistema. Puede describir tambin cmo deben ser probados aspectos especficos del sistema. Es una coleccin de casos de prueba, procedimientos de prueba y componentes de prueba.

V2.0. Ver apunte.

Pgina 25 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

Caso de Prueba: especifica una forma de probar el sistema incluyendo la entrada o resultado con la que se ha de probar y bajo las condiciones bajo las que ha de probarse. Casos de pruebas comunes: CP que especifica como probar un CU o escenario especifico de un CU. (C. Negra) CP que especifica como probar una realizacin de CU-diseo o un escenario especifico de la realizacin. (Caja blanca) Procedimiento de Prueba: especifica cmo realizar uno o varios casos de prueba o partes de estos. A menudo es til reutilizar un procedimiento de prueba para varios casos de prueba y reutilizar varios procedimientos de prueba para un caso de prueba. Componente de prueba: Automatiza una o varios procedimientos de prueba o parte de ellos. Pueden ser desarrollados utilizando lenguaje de guiones o un lenguaje de programacin, o pueden ser grabados con una herramienta de automatizacin de pruebas. Se utilizan para probar componentes en el modelo de implementacin, proporcionando entradas de pruebas, controlando y monitoreando la ejecucin de los componentes a probar, informando de los resultados de las pruebas. Plan de prueba: describe las estrategias, recursos y planificacin de la prueba. La estrategia de la prueba incluye la definicin del tipo de prueba a realizar para cada iteracin y sus objetivos, el nivel de cobertura de prueba y el cdigo necesario y el porcentaje de pruebas que deberan ejecutarse con un resultado especfico. Defecto: es una anomala del sistema. Puede ser utilizada para localizar cualquier cosa que los desarrolladores necesitan registrar como sntoma de un problema en el sistema que ellos necesitan controlar y resolver. Evaluacin de prueba: es una evaluacin de los resultados de los esfuerzos de prueba, tales como la cobertura del CP, la cobertura del cdigo y el estado de los defectos. 4.1.3. Trabajadores de la Prueba: Diseador de pruebas: Responsable de la integridad del modelo de pruebas, asegurando que el modelo cumple con su propsito. Planean las pruebas (deciden los objetivos de pruebas apropiados y la planificacin de las pruebas) Seleccionan y describen los casos de prueba y los procedimientos de prueba correspondientes que se necesitan. Responsables de la evaluacin de las pruebas de integracin y de sistemas cuando stas se ejecutan. Ingeniero de Componentes: es el responsable de los componentes de prueba que automatizan algunos de los procedimientos de prueba. Ingeniero de Pruebas de Integracin: responsable de realizar las pruebas de integracin que se necesitan para cada construccin producida en el flujo de trabajo de la implementacin. Se encarga de documentar los defectos en los resultados de las pruebas de integracin. Ingeniero de Pruebas de Sistema: responsable de realizar las pruebas de sistemas necesarias sobre una construccin que muestra el resultado de una iteracin completa. Se encarga de documentar los defectos en los resultados de las pruebas de sistema. 4.1.4. Actividades de la Prueba: Planificar Prueba: el propsito es planificar los esfuerzos de prueba en una iteracin llevando a cabo las siguientes tareas: Describiendo la tarea de prueba. Estimando los requisitos para el esfuerzo de la prueba. Planificando el esfuerzo de la prueba. Disear Prueba: propsitos de disear pruebas: Identificar y describir los casos de prueba para cada construccin: se disean los casos de prueba de integracin, de sistemas y de regresin. Identificar y estructurar los procedimientos de prueba especificando cmo realizar los casos de prueba.

V2.0. Ver apunte.

Pgina 26 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

Implementar prueba: el propsito es automatizar los procedimientos de prueba creando componentes de prueba si esto es posible. Realizar pruebas de Integracin: se realizan las pruebas de integracin necesarias para cada una de las construcciones creadas en una iteracin y se recopilan los resultados de las pruebas. Se llevan a cabo los siguientes pasos: Realizar las pruebas de integracin relevantes a la construccin. Comparar los resultados de las pruebas con los resultados esperados. Informar de los defectos a los ingenieros de componentes. Informar de los defectos a los diseadores de pruebas. Realizar pruebas de sistemas: propsito de evaluar los esfuerzos de prueba en una iteracin, comprobando los resultados obtenidos con los objetivos esbozados en el plan de prueba. Los diseadores de pruebas preparan las mtricas que le permiten determinar el nivel de calidad del software y que cantidad de pruebas es necesaria. El ingeniero de pruebas observa 2 mtricas: Complecin de la prueba y Fiabilidad. 4.2. Niveles de Prueba: 4.2.1. Unitario: Nivel de prueba ms bajo realizada por el desarrollador, se prueban clases, bloques, paquetes de servicio. Esta prueba consiste de: Prueba de especificacin o Caja Negra: verifican el comportamiento de la interfaz de la unidad. Previamente se definieron las operaciones que soporta la unidad y el comportamiento que debera mostrar para cada operacin, en base a esto se verifica que la unidad produzca salidas y que las mismas sean correctas. Prueba estructural o de Caja Blanca: verificar si la estructura interna es correcta. Deben ser contemplados y ejecutados todos los caminos posibles planteados en el cdigo considerando parmetros y los valores de las variables. Prueba basada en estados: prueba la interaccin entre las operaciones de una clase, monitoreando los cambios que tienen lugar en los atributos de los objetos. 4.2.2. De Integracin: El objetivo es probar que las unidades trabajan correctamente juntas. Se incluyen pruebas de paquetes de servicio, de CU, subsistemas y el sistema completo. Estas pruebas son necesarias porque: al combinar las unidades aparecen nuevas fallas y aumenta el nmero de caminos posibles. Los CU son la herramienta que conduce la prueba de integracin, donde cada CU se prueba en un punto de vista externo y otro interno. Se hacen para un CU las siguientes pruebas: Pruebas de curso bsico Pruebas de curso alternativos Pruebas de documentacin de usuario 4.2.3. De Sistema: Se prueba el sistema completo. Requiere la colaboracin de un usuario final y de CP tpicos. Estos se dividen en: Test de Operacin, Test de Escala Completa; Test Negativos; Test basados en ERS; Test de Documentacin de Usuario. Proceso de Prueba La prueba: El propsito de la prueba es encontrar fallas o defectos cuya presencia se asume La prueba es un proceso destructivo para detectar lo que se hizo mal La correccin de una falla provoca fallas adicionales Tipos de Pruebas: Test de Operacin: el sistema es probado en operacin normal. Mide la confiabilidad del sistema y se puede obtener mediciones estadsticas. Test de Escala Completa: se ejecuta el sistema al mximo, todos los parmetros enfocan a valores mximos. Test de Performance o de Capacidad: el objetivo es mediar la capacidad de procesamiento del sistema. Test de Sobrecarga: para determinar como se comporta el sistema cuando es sobrecargado. V2.0. Ver apunte.

Pgina 27 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

Test Negativos: el sistema es sistemticamente e intencionalmente usado en forma incorrecta. Lo cual debe ser planeado para probar cosas especiales. Test basados en requerimientos: pueden mapearse directamente desde la ERS Test Ergonmicos: importantes si el sistema ser usado por gente inexperta para probar cosas como: consistencia de la interfaz, consistencia entre las interfaces de distintos CU, si los mens son lgicos y legibles, si se entienden los mensajes de falla. Test de documentacin de usuario: se prueba la documentacin del sistema. Test de Aceptacin: ejecutado por la organizacin que solicita el sistema, el cual es probado en un entorno real (alfa). Si no hay usuario solicitante se usan las pruebas betas (ejecutadas por clientes selectos antes de liberar la versin). Estrategias de prueba: las estrategias de pruebas suelen hacerse en el orden inverso al que se hizo el diseo y la implementacin. Se pueden desarrollar de varias maneras: Top-down, Bottomup.... En el enfoque Top-Down primero se desarrollan las interfaces entre subsistemas. El enfoque bottom-up es preferible en los niveles ms bajos, cuando la primera unidad est certificada y los clientes directos pueden ser certificados. El proceso de prueba: es un proceso que en gran medida corre en paralelo con otros procesos por lo que es importante plantearla. Las actividades del proceso son: 1. Planificacin de la prueba: puede comenzar en el anlisis pero no se puede preparar nada hasta no comenzar la construccin. Los lineamientos de la prueba se establecen con anticipacin, determinando: Si las pruebas se harn manual o automticamente. Hacer una estimacin de recursos que se requerirn. Si existen programas de prueba y datos que pueden usarse, si deberan modificarse o crearse nuevos. Utilizando estos lineamentos como base se pueden determinar el grado de cobertura que tendran los test. El plan debe servir como base para las actividades de prueba. Se debe mantener un registro de la prueba. 2. Identificacin de la prueba: cuando se identifica lo que se debe probarse se puede realizar una estimacin ms detallada sobre recursos requeridos (configuracin y determinacin de equipamiento). Esta simulacin es el principal lineamiento para la especificacin y ejecucin de la prueba. 3. especificacin de la Prueba: su propsito es dar instrucciones detalladas para correr los CP (indicndose como debe ejecutarse, en que orden, salidas esperadas y criterio para aprobar el test). Al identificar que subtest se harn se especifican a nivel funcional (descripcin de la prueba y propsito) y en un nivel detallado (cmo ser ejecutado, con una descripcin procedural completa de cada paso en la prueba. (Se preparan reportes requeridos para informar resultados de las pruebas) 4. Ejecucin de las pruebas: para la ejecucin se usa la especificacin de pruebas y los reportes de pruebas. Las especificaciones indican el resultado esperado. Los reportes contienen el resultado individual de cada subtest y uno final, recursos gastados y si el test est aprobado o no. 5. Anlisis de Error: si se detectan fallas cuando se hizo el test se debe encontrar la razn de la misma. Puede haber varias causas: Falla en los datos o programas de prueba Falla causada por los bancos de prueba 5.1. Flujo de Trabajo de Despliegue: 5.1.1. El Rol del Despliegue en el Ciclo de Vida del Software: Las actividades de despliegue hacen un pico en la fase de transicin y representan la culminacin del esfuerzo del desarrollo de programas. El propsito de la fase de transicin, as como la meta de las actividades del despliegue, es asegurar la transicin sin problemas de un usuario autosuficiente al nuevo software. El planeamiento del despliegue puede comenzar temprano en el ciclo de vida del proyecto, a explicar el desarrollo del despliegue y la estrategia de preparacin del cliente y los recursos necesarios para entregar el material de ayuda probado del producto y del usuario final. 5.1.2. Artefactos del Despliegue: V2.0. Ver apunte.
Pgina 28 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

Los artefactos requeridos dependen del modo del despliegue: Release: artefacto dominante que puede consistir en: Software ejecutable Artefactos de la instalacin: script, herramientas, archivos, guas, etc. Notas de release: describiendo el release para el usuario final Material de ayuda (manual de usuario, operaciones, manual de mantenimiento) Material de entrenamiento. Artefactos adicionales (shrink-wrapped) Lista de materiales: lista completa de elementos que se incluirn en el producto manufacturado. Release principal: las capas de los medios de presentacin se hacen del principal. Empaquetado: el envase del producto. Ilustraciones del producto: parte del empaquetado para ayudar con la identificacin y marca del producto. Especificacin impresa: el material textual que acompaa el producto Medios de presentacin: material en el cual se presenta el producto Otros artefactos de despliegue, no necesariamente presentados al cliente: - Resultados de prueba - Resultados de la retroalimentacin de la prueba beta. - Resumen de la evaluacin de la prueba. 5.1.3. Trabajadores del Despliegue: Encargado de despliegue: planea y organiza el despliegue. Es responsable de la retroalimentacin de la prueba del programa beta y asegura que el producto es empaquetado apropiadamente para el envo. Gestor de Proyecto: es quien se relaciona con el cliente y es responsable de aprobar el despliegue basado en evaluaciones de la retroalimentacin y del resultado de la prueba y de la aceptacin del cliente de la entrega. Escritor tcnico: planea y produce el material de ayuda del usuario final. Desarrollador del curso: planea y produce el material de entrenamiento Artista grfico: responsable de todas las ilustraciones relacionadas con el producto. Probador (Tester): ejecuta las pruebas de aceptacin y es responsable de asegurarse de que el producto se ha probado adecuadamente. Implementador (Desarrollador): crea los script de la instalacin y los artefactos relacionados que ayudarn al usuario final a instalar el producto. 5.1.4. Actividades del Despliegue: Despliegue del plan: el planeamiento del despliegue debe describir cmo y cundo ser desarrollada la lista completa de productos a entregar. Debe asegurarse que el usuario final tiene toda la informacin necesaria para tomar la entrega del nuevo software. El planeamiento requiere un alto de colaboracin y preparacin del cliente. Desarrollo del material de ayuda: el material de ayuda cubre la gama de informacin completa que ser requerida por el usuario final para instalar, gestionar, utilizar y mantener el sistema entregado. (Incluye material de entrenamiento) Crear el release: el propsito es asegurarse que el producto est preparado para la entrega al cliente. Un release consiste en todo lo que el usuario necesita para instalar y correr el software. Release de la prueba beta: la prueba beta requiere que el software entregado sea instalado por el usuario final, que proporciona la retroalimentacin de su funcionamiento y utilidad. La prueba beta es esencial para asegurarse que las expectativas del cliente estn resueltas. Probar el producto en el sitio de instalacin: despus de la prueba interna y beta, el producto necesita ser instalado en el sitio y ser probado por el cliente. (Formalidad) Producto empaquetado: estas actividades opcionales describen que necesita de ocurrir para producir productos de software embalados. Proporcione el acceso al sitio de transferencia directa: el atractivo del comercio Web y de Internet como canal de distribucin de software es obvia. El producto es accesible a travs del entorno informtico de browsers y sitios Web.

V2.0. Ver apunte.

Pgina 29 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

5.2. Estrategias de Cambio en el Software: Los sistemas de software siempre evolucionan en respuesta a las demandas del cambio (porque emergen nuevos requerimientos, para corregir errores, para mejorar su desempeo). Existen varias estrategias para cambiar el software: Mantenimiento de Software, Transformacin Arquitectnica y Reingeniera de Software. 5.2.1. Dinmica de la evolucin del software: Es el estudio de los cambios en el sistema. Lehman y Belady proponen un conjunto de leyes que se refieren al cambio en los sistemas. Estas leyes son invariantes y de aplicacin amplia: 1ra Ley: Cambio continuo: un programa utilizado en un entorno real necesariamente debe cambiar o llega a ser progresivamente menos til en ese entorno. 2da Ley: Incremento de la complejidad: puesto que un programa evolutivo cambia, su estructura tiende a ser ms compleja. Se deben dedicar recursos extra para preservar y simplificar la estructura. 3ra Ley: evolucin prolongada del programa: la evolucin del programa es un proceso auto regulatorio. Los atributos del sistema, como el tamao, el tiempo entre entregas y el nmero de errores reportados son aproximadamente invariante para cada entrega del sistema. 4ta Ley: estabilidad organizacional: en el tiempo de vida de un programa, su tasa de desarrollo es aproximadamente constante e independiente de recursos dedicados al desarrollo del sistema. 5ta Ley: Conservacin de la familiaridad: en el tiempo de vida del sistema, el cambio incremental en cada entrega es aproximadamente constante. 5.2.2. Mantenimiento del Software: Proceso para cambiar un sistema despus de que se entreg. El mantenimiento es una continuacin natural del proceso de desarrollo del sistema con actividades asociadas de especificacin, diseo, implementacin y pruebas. Existen 3 tipos de mantenimiento de software: Mantenimiento para reparar las fallas del software: corregir errores de codificacin (baratos), errores de diseo (costosos), errores de requerimientos (muy costosos rediseo amplio del sistema). Mantenimiento para adaptar el software a diferentes entornos operativos: este tipo de mantenimiento se requieren cuando cambian algunos aspectos del entorno del sistema. Mantenimiento para agregar o modificar la funcionalidad del sistema: es necesario cuando los requerimientos del sistema cambian como respuesta a los cambios organizacionales o de negocio. Los factores que conducen a costos de mantenimiento altos son: Estabilidad del equipo: el equipo de desarrolladores no es el mismo que el equipo que realiza el mantenimiento por lo que se invierte demasiado esfuerzo en comprender el sistema antes de implementar los cambios. Responsabilidad contractual: el contrato para mantener un sistema est separado del contracto de desarrollo. Lo cual no incentiva al equipo de desarrollo para generar un software fcil de cambiar. Habilidades del Personal: personal de mantenimiento es relativamente inexperto y no est familiarizado con el dominio de aplicacin. Edad y Estructura del programa: conforme el programa aumenta su edad, su estructura tiende a degradarse por los cambios, por lo que es ms difcil comprenderlo y cambiarlo. Proceso de mantenimiento: los procesos de mantenimiento varan dependiendo del tipo de software a dar mantenimiento, procesos de desarrollo y las personas involucradas. El proceso de mantenimiento se dispara por un conjunto de de peticiones de cambios provenientes de los usuarios del sistema, los administradores o los clientes. Si se aceptan los cambios se planea una nueva versin que considera todos los cambios propuestos. Los cambios urgentes surgen por 3 razones: Emergencia de una falla del sistema. (no permiten operacin normal del sistema) Cambios en el entorno (que provocan efectos inesperados) V2.0. Ver apunte.
Pgina 30 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

Cambios no anticipados (nuevos competidores/nueva legislacin) Prediccin del mantenimiento: tratar de predecir que cambios se solicitarn al sistema. Las predicciones estn relacionadas con: Aceptacin o no del cambio depende de la mantenibilidad de los componentes afectados. La implementacin de cambios degrada la estructura y reduce su mantenibilidad. Costos de mantenimiento depende del nmero de cambios y el costo de la implementacin del cambio depende la mantenibilidad de los componentes. Predecir el nmero de peticiones de cambio requiere entender la relacin entre el sistema y su entorno, para lo cual se evala: Nmero y complejidad de las interfaces del sistema. Nmero de requerimientos inherentemente voltiles del sistema. Procesos de negocio en los que se utiliza el sistema. Para predecir la mantenibilidad se necesita comprender el nmero y el tipo de relacin ente los componentes y la complejidad inherente de estos componentes. Para ayudar a predecir la mantenibilidad existen ciertas mtricas de proceso tiles para evaluar la mantenibilidad: Nmero de peticiones de mantenimiento correctivo. Tiempo promedio requerido para el anlisis de impacto. Tiempo promedio para implementar una peticin de cambio. Nmero de peticiones de cambio pendientes. 5.2.3. Evolucin Arquitectnica: Muchas compaas se enfrentan a la necesidad de evolucionar sus sistemas centralizados mainframe a sistemas distribuidos cliente-servidor. Conductores que contribuyen al cambio: Costos de Hardware: menores costos de mantenimiento a sistemas distribuidos Cliente-Servidor Expectativas de la interfaz de usuario. Acceso distribuido a los sistemas (sistemas de cmputos accesibles desde diferentes partes) Una dificultad fundamental al migrar sistemas heredados, es que los sistemas no estn estructurados de tal manera que los componentes arquitectnicos bsicos se puedan identificar y separar de los otros componentes. Hay situaciones en las que no es prctico dividir el sistema heredado en componentes distribuibles, entonces, se utiliza un enfoque alternativo: el sistema heredado se congela y el completo se empaqueta como servidor. La interfaz de usuario se re-implementa en el cliente y el middleware de propsito especial traduce las peticiones del cliente en interacciones con el sistema legado sin cambio. Distribucin de la interfaz de usuario: los sistemas heredados utilizaban interfaces basadas en formularios que solo desplegaban caracteres. La distribucin de la interfaz de usuario aprovecha el poder local de procesamiento disponible de las computadoras de escritorio para suministrar una interfaz grfica ms adecuada para los usuarios del sistema. Existen 2 estrategias de implementacin para la distribucin de interfaces de usuario: Implementar la interfaz utilizando el sistema de administracin de ventanas nativo de la PC cliente e implementar comunicaciones con el servidor. Implementar la interfaz de usuario utilizando un navegador www. 5.2.4. Reingeniera de Software: Comprende la redocumentacin del sistema, la organizacin y reestructura del sistema, la traduccin del sistema a un lenguaje de programacin ms moderno y la modificacin y actualizacin de la estructura y los valores de los datos del sistema. La reingeniera tiene 2 ventajas para la evolucin de sistemas: riesgo reducido y costo reducido: Las actividades del proceso de reingeniera son: Traduccin del cdigo fuente: forma ms simple de reingeniera de software. Esta es necesaria debido a: actualizacin de plataforma de hardware, debilidad en las habilidades del personal, cambios en las polticas organizacionales, falta de software de apoyo. Ingeniera inversa: proceso de analizar el software para recuperar su diseo y especificacin a partir de su cdigo fuente, para ayudar a comprender un programa antes de reorganizar su estructura. V2.0. Ver apunte.
Pgina 31 de 32

UTN-FRC-Diseo de Sistemas

Mara Florencia Ruiz

Mejora de la estructura del programa: se analiza y modifica la estructura de control del programa para hacerlo ms fcil de leer y comprender. Problema con la reestructuracin automtica: prdida de comentarios y documentacin y demandas de computacin pesadas. Modularizacin del programa: proceso de reorganizar un programa con el fin de que las partes relacionadas se ubiquen conjuntamente y se consideren como un solo mdulo para que sea ms fcil eliminar la redundancia en los componentes relacionados, optimizar sus interacciones y simplificar su interfaz con el resto del programa. En este proceso se crean mdulos diferentes: o Abstracciones de datos: tipos de datos abstractos creados al asociar los datos con componentes de procesamiento. o Mdulos de Hardware: recolectan conjuntamente las funciones utilizadas para controlar un dispositivo. o Mdulos funcionales: recolectan conjunto de funciones que llevan a cabo tareas similares o relacionadas. o Mdulos de apoyo al proceso: funciones y elementos para apoyar un proceso de negocio. Reingeniera de cdigo: proceso de analizar y reorganizar las estructuras y los valores de los datos de un sistema para hacerlo ms comprensible. Razones para modificar los datos: o Degradacin de los datos. o Limites inherentes construidos en el programa o Evolucin arquitectnica Problemas que pueden surgir con los datos en sistemas heredados compuestos: o Problemas con los nombres de los datos o Problemas con la longitud de los datos o Problemas en la organizacin de los registros o Literales fuertemente codificados o No existencia de un diccionario de datos.

V2.0. Ver apunte.

Pgina 32 de 32