Unidad #1 Fundamentos de Diseño

Repblica Bolivariana de Venezuela Universidad Politcnica del Oeste Mariscal Sucre
Unidad Curricular:: INGENIERIA DE SOFTWARE II Modulo: Fundamentos del Diseo de Software Apuntes Recopilados por: Profesor Bernardo Gonzlez Rojas
UNIDAD N 1 FUNDAMENTOS DE DISEO.

1.- DISEO DE SOFTWARE. 1.1.- Introduccin.
El diseo es el primer paso de la fase de desarrollo de cualquier producto o sistema de ingeniera. Puede definirse como: "El proceso de aplicar distintas tcnicas, herramientas y principios sin el propsito de definir un dispositivo, proceso o sistema; con los suficientes detalles como para permitir su realizacin". El diseo del software requiere de precisin y de creatividad, por parte del diseador; su propsito es: Especificar la estructura interna y los detalles de procesamiento de un sistema y proporcionar un ensayo de revisin del por qu fueron timadas las decisiones de diseo. El Diseo del sistema es el proceso de describir, organizar y estructurar los componentes del sistema. Tanto a nivel arquitectnico como a nivel detallado, con la intencin de construir el sistema propuesto. El diseo de ms alto nivel tambin es llamado: diseo general, arquitectnico o conceptual. Tambin es una actividad de modelaje. La informacin modelada en la identificacin de los requerimientos se convierte en modelos que representan la solucin.
1.2.- Objetivo.
El objetivo del diseador es producir un modelo o representacin de una entidad que se construir ms adelante. El proceso por el cual se desarrolla el modelo combina:
La intuicin y los criterios sobre la base de la experiencia de construir entidades similares, Un conjunto de principios y/o heursticas que guan la forma en que se desarrolla el modelo, Un conjunto de criterios que permiten discernir sobre la calidad y un proceso de iteracin que
conduce finalmente a una representacin del diseo final. El objetivo del diseador es producir un modelo o representacin del software que se continuara ms adelante. El diseo del software es una afirmacin de requisitos del usuario y la realizacin de estos en la forma de cdigo ejecutable. Una vez establecidos los requisitos del software, el diseo del software es la primera de tres (3) actividades tcnicas:
i.- Diseo. ii.- Codificacin. iii.- Prueba.

Cada actividad transforma la informacin de forma que finalmente se obtiene un software para computadora valido. El diseo es un proceso de resolucin de problemas cuyo objetivo es encontrar y describir una forma
Para implementar los requisitos funcionales del sistema

Respetando las restricciones impuestas por los requisitos no funcionales Incluyendo las presupuestarias Ajustndose a los principios generales de calidad
El proceso de diseo es, por tanto, un proceso iterativo, mediante el cual se va a realizar una traduccin de los requisitos en una representacin del software. El diseo del software se asienta en el ncleo tcnico del proceso de ingeniera del software y se aplica independientemente del paradigma de desarrollo utilizado. Mediante alguna de las metodologas de diseo se realiza el diseo de datos, el diseo arquitectnico y el diseo procedimental.
1.3.- Diseo de Datos.

Transforma el modelo del campo de informacin, creado durante el anlisis, en las estructuras de datos que se van a requerir para implementar el software.
1.1.3.- Diseo Arquitectnico:

Define las relaciones entre los principales elementos estructurales del programa.
1.5.- Diseo Procedimental:

Transforma los elementos estructurales en una descripcin procedimental del software. Se genera el cdigo fuente y para integrar y validar el software, se llevan a cabo las pruebas.
2.- IMPORTANCIA DEL DISEO DE SOFTWARE. 2.1.- Introduccin.

La importancia del diseo del software se puede sentar con una nica palabra calidad. El diseo es el proceso en el que se asienta la calidad del desarrollo del software. El diseo produce las representaciones del software de las que puede evaluarse su calidad. El diseo es la nica forma mediante la cual podemos traducir con precisin los requisitos del cliente en un producto o sistema acabado. El diseo de software sirve como base de todas las posteriores etapas del desarrollo y de la fase de mantenimiento. Sin diseo nos arriesgamos a construir un sistema inestable, un sistema que falle cuando se realicen pequeos cambios; un sistema que pueda ser difcil de probar; un sistema cuya calidad no pueda ser evaluada hasta ms adelante en el proceso de ingeniera del software, cuando quede poco tiempo y se haya gastado ya mucho dinero.
2.2.- Alcance del Diseo del Software.

Cubre un rango amplio de actividades en dos (2) reas:
Diseo de la arquitectura del sistema: Este es el proceso durante el cual se produce una
especificacin completa y verificada del hardware en general.
Diseo detallado del software: Este ocurre cuando se producen especificaciones verificadas de
estructuras de datos. El diseo detallado que se ocupa del refinamiento de la representacin arquitectnica que lleva a una estructura de datos detallada y a las representaciones algortmicas del software. Adems del diseo de datos, arquitectnico y procedimental, muchas aplicaciones modernas requieren del diseo de interfaz que establece la disposicin y los mecanismos para la interaccin hombre-mquina.
3.- PERSISTENCIA Y ALMACENAMIENTO. 3.1.- Introduccin.

La mayor parte de las aplicaciones actuales requieren algn tipo de esquema de persistencia, es decir, algn medio a travs del cual almacenar la informacin una vez finalizada su ejecucin y recuperarla cuando sea preciso.
La eleccin de un mecanismo de persistencia adecuado a los propsitos del sistema que se pretende desarrollar supone la toma de un conjunto de decisiones:
El tipo de sistema de base de datos a utilizar. La forma en que la aplicacin se comunicar con el mismo.
La distribucin de la lgica: qu parte resolver la aplicacin y qu otra se delegar a mecanismos propios del sistema elegido (stored procedures, consultas precompliladas o vistas, etc). El grado de automatizacin para los accesos (consultas, etc).
Los requerimientos de rendimiento o efectividad (performance). 3.2.- Uso de Base de Datos Orientada a Objetos.
En general, algunas de las cuestiones planteadas han encontrado cierto consenso a la hora de disear una solucin. En cuanto a la eleccin del mecanismo de persistencia, nos encontramos, por ejemplo, con las bases de datos de objetos (OODBMS). Como su nombre lo indica, la forma en la que stas organizan y almacenan la informacin se acerca bastante a la manera en que se trabaja con objetos y referencias en las aplicaciones OO, por lo que la transicin entre aplicacin y base de datos prometera ser ideal. Sin embargo, por diversas razones no han ganado la suficiente popularidad en el mercado, entre las que se encuentran la necesidad de la independencia de datos, es decir, que la informacin se encuentre almacenada de forma tal que sea til a cualquier aplicacin, desarrollada a travs de cualquier tecnologa. La utilizacin de archivos para el mecanismo de persistencia trae aparejados sus propios inconvenientes. En el caso de los archivos XML habr que unificar los conceptos de orientacin a objetos con el enfoque jerrquico. Por otro lado, la cuestin del almacenamiento de la informacin impone necesidades en torno a la forma de organizar y recuperar los datos en forma eficiente, y un simple archivo no puede proporcionarnos ninguna ventaja en relacin con estos aspectos.
3.3.- Uso de Base de Datos Relacionales.

Por su parte, las bases relacionales (RDBMS) han demostrado poseer caractersticas deseables a la hora de seleccionar un sistema de almacenamiento de la informacin: Constituyen una aproximacin robusta y flexible para el manejo de los datos. Se encuentran soportadas por una teora capaz de, entre otras cosas, asegurar la integridad de la informacin. En general son independientes de la aplicacin que haga uso de los datos. No dependen de ningn lenguaje ni paradigma de programacin, por lo que pueden ser tiles a aplicaciones de la ms variada naturaleza y tecnologa. Estn sustentadas por estndares. forma de acceder y recuperar los datos. Poseen una amplia aceptacin en el mercado, y en general la mayora de las organizaciones cuentan con una.
Han experimentado una mejora continua a lo largo de los aos en cuanto a la optimizacin en la
Habiendo escogido un sistema de estas caractersticas podramos considerar resueltos algunos de los inconvenientes bsicos que trae aparejado el desarrollo de una aplicacin que requiera un mecanismo de persistencia de la informacin, ya que ciertas cuestiones se delegan al motor: Almacenamiento, organizacin y recuperacin de informacin estructurada. Concurrencia e integridad de datos. Administracin de los datos compartidos.
3
Como vemos, la decisin a favor de un RDBMS parece convincente, sin embargo, an resta abordar la cuestin de cmo comunicar la base de datos con nuestra aplicacin para permitir que el estado de nuestros objetos pueda ser eventualmente almacenado en disco y recuperado tiempo ms tarde.
4.- METODOS PARA LA ACTIVIDAD DE DISEO DE SOFTWARE. 4.1.-Notaciones en Diseo de Software y Documentacin.
Existen numerosas notaciones para representar artefactos de diseo. Algunas se usan durante el diseo arquitectnico, otras durante el detallado y otras en ambas. Se han caracterizado las notaciones en trminos de caja negra versos caja blanca:
Notacin caja negra: se preocupa con las propiedades externas de los elementos del modelo de
diseo
Notacin caja blanca: se preocupa mayormente con describir algunos aspectos de la realizacin
detalladas de un elemento de diseo Otra forma es diferenciarlas entre notaciones para describir propiedades estructurales (estticas) y las que describen propiedades conductuales (dinmicas)
4.2.- Algunas Descripciones Estructurales (Vista Esttica).

Diagramas de clase y objeto: se usan para representar un conjunto de clases (y objetos) y sus relaciones. Una notacin antigua relacionada son los diagramas entidad-relacin, usados para representar modelos conceptuales de datos almacenados en sistemas de informacin. UML tiene esta notacin Diagramas de componentes: se usan para modelas la vista de implementacin estticas de un sistema, es decir, cosas fsicas (y sus relaciones) como ejecutables, libreras, tablas, archivos y documentos. A pesar que si uso principal es durante la construccin, estos diagramas pueden ser usados durante diseo, por ejemplo, para documentar la estructura de un mdulo. UML tiene esta notacin Diagramas de deployment: se usan para modelar la vista de deployment esttico de un sistema, es decir, la configuracin de nodos de procesamiento en tiempo de ejecucin y los componentes que viven en ellos. Tpicamente estos diagramas pueden ser usados para representar aspectos de distribucin, por ejemplo un modelo empotrado, cliente/servidor o sistemas distribuidos. UML tiene esta notacin Cartas de estructuras o Diagrama de Estructura: se usan para describir la estructura de llamado de unos programas, es decir, cul mdulo es invocado por otro mdulo. Estos diagramas son inherentes de la aproximacin de diseo orientado a la funcin.
4.3.- Algunas Descripciones Conductuales (Vista Dinmica)

Diagramas de actividad: se usan para mostrar el flujo de control de actividad (ejecucin continua no-atmica dentro de una mquina de estado) a otra actividad. UML tiene esta notacin. Diagramas de interaccin: se usan para mostrar las interacciones entre un grupo de objetos. Estos diagramas vienen en dos tipos: diagramas de secuencia ponen el nfasis en el ordenamiento temporal de los mensajes, mientras que los diagramas de colaboracin ponen el nfasis en los objetos, sus enlaces y los mensajes que intercambian en estos enlaces. UML tiene esta notacin. Diagramas de flujo de datos: se usan para mostrar el flujo de datos entre un conjunto de procesos. Diagramas de transicin de estados y diagramas de statecharts (utilizados en UML): se usan para mostrar el flujo de control de estado a estado en una mquina de estados. Pseudocdigo y lenguajes de diseo de programas: son lenguajes estructurados similares a programacin que se usan para describir en la etapa de diseo detallado la conducta de un procedimiento o mtodo.
4.4.- Documentacin de Diseo.
Dada la variedad de notaciones disponibles, se presenta la dificultad de cmo combinarlas para confeccionar un documento de diseo coherente. No hay respuesta definitoria. Depende de muchos aspectos: tipo de software a desarrollar, las personas involucradas, etc. La seleccin de un conjunto apropiado de vistas depende de las personas involucradas: administradores de proyectos, desarrolladores, testeadores e integradores, clientes, usuarios finales, etc. Satisfacer las diferentes necesidades se puede describir en trminos de la importancia relativa de las varias vistas desde cada tipo de vista: mdulo, componente-y-conector y asignacin (allocation). Un administrador del proyecto podra requerir vistas de asignacin detalladas mientras que un desarrollador podra requerir vistas de mdulos y componente-y-conector ms detalladas. Documentar una vista involucra por lo menos, el describir las interfaces de los elementos de esa vista. La definicin de esa vista depender del tipo de elemento. Una clave caracterstica de cada especificacin de interface es que tiene que ser dual: lo que el elemento provee y lo que requiere (los recursos usados por el elemento y las suposiciones que hace del medio ambiente). Otra idea clave es que el diseo debe ser presentado y documentado en una forma racional, aunque el proceso que lo haya guiado no haya sido perfectamente racional.
5.- PRINCIPIOS DEL DISEO: ITERACION ENTRE DISEO Y REQUERIMIENTOS.5. 5.1.- Criterios.
Restricciones: Son las razones por las que el rango completo de elecciones abiertas a un diseador serian restringidas. Estas pueden ser: Contractuales: Cuando los componentes requieren que se sigan ciertos procedimientos o mtodos a ser utilizados. Tcnicos: El hardware y software existente limitan la libertad del diseador desde el principio. Expectativas del cliente: La participacin del cliente influye en la estrategia del diseo adoptada. Tipo de sistema: El sistema que se desarrolla es el que permite la eleccin de los mtodos de diseo y herramientas. Tipo de aplicacin: Las implicaciones de disear un sistema de garanta o seguridad crtica son diferentes del diseo de un prototipo inhouse. Ambiente del proyecto: Esta referido, al ambiente en el que trabajamos desde el punto de vista fsico y en cuanto al ambiente del diseo en general; requisitos que ya tenemos planteados en el diseo. Vista completa del ciclo de vida: Es el conjunto de actividades que los analistas, diseadores y usuarios realizan para desarrollar e implementar un sistema de informacin. Requerimientos no funcionales: Esta referido a los materiales y equipos que no son funcin del sistema; pero que necesito para llevarlo a cabo.
6.- DISEO DE ATRIBUTOS DE CALIDAD. 6.1.- Proceso y Calidad del Diseo.

El diseo del software es un proceso iterativo mediante el cual los requerimientos se traducen en un plano para construir el software. Para lograr que un diseo sea presentable se deben seguir ciertas pautas. Existen ciertos criterios que son los que evalan el diseo del software, estos criterios son: Un diseo debe mostrar una organizacin jerrquica. En diseo debe ser modular. Un diseo debe contener representaciones distintas y separadas de los datos y procedimientos. Debe llevar a mdulos. Debe llevar interfaces que reduzcan la complejidad.
5
Debe obtenerse el diseo mediante un modulo reproducible.
6.2.- Caractersticas Para la Evaluacin. Implementar todos los requisitos explcitos contenidos en el modelo de anlisis, y ajustarse a
todos los requisitos del cliente.
Debe ser una gua legible y comprensible para quienes generan el cdigo y quienes realizan
pruebas, es decir, dan soporte al software.
Debe proporcionar una imagen completa del software desde una perspectiva de implementacin. 6.3.- Cmo Alcanzar las Metas del Proceso?. Un diseo debe presentar una estructura arquitectnica que se halla creado mediante patrones de diseo reconocibles, la integren componentes que exhiban buenas caractersticas de diseo y
que pueda implementarse de manera evolutiva para que de estar forma facilite la implementacin y las pruebas. Un diseo debe ser modular. Un diseo debe contener distintas representaciones de los datos, la arquitectura, las interfaces y los componentes. habrn de implementarse y que procedan de patrones de datos reconocibles. Un diseo debe independientes. conducir a componentes que representan caractersticas funcionales
Un diseo debe conducir a estructuras de datos que sean apropiadas para las clases que
Un diseo debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los
componentes y el ambiente externo. Un diseo debe obtenerse por medio de un mtodo repetible que se base en la informacin obtenida durante el anlisis de requisitos del software. Un diseo debe representarse por medio de una notacin que comunique de manera eficaz su significado.
6.4.- Caractersticas.
La funcionalidad. La facilidad. La confiabilidad. El desempeo. La soportabilidad, la adaptabilidad y la servicialidad.
7.- EVOLUCION DEL DISEO DE SOFTWARE. 7.1.- Historia.

El contexto en el que se ha desarrollado el software est fuertemente ligado a la evolucin de los sistemas informticos. Un mejor rendimiento del hardware, una reduccin del tamao y un costo ms bajo, han dado lugar a sistemas informticos ms sofisticados. La evolucin del software dentro del contexto de las reas de aplicacin de los sistemas basados en computadoras, puede verse de la siguiente manera:
6
Los primeros aos

1950 - 1965
La segunda era
1965 - 1975
La tercera era
1975 - 1985
La cuarta era
1985 -
Orientacin por lotes Distribucin limitada Software a medida
Potentes sistemas de Sistemas distribuidos escritorio Multiusuario Incorporacin de Tecnologa orientada Tiempo real inteligencia a objetos Bases de Datos Hardware de bajo Sistemas expertos costo Software como Redes neuronales producto Impacto en el artificiales consumo Computacin paralela
En los primeros aos de desarrollo de las computadoras, el hardware sufri continuos cambios, mientras que el software se contemplaba simplemente como un aadido. La programacin de computadoras era un arte para el cual existan pocos mtodos sistemticos. El desarrollo de software se realizaba virtualmente sin ninguna planificacin (hasta que los planes comenzaron a desfasarse y los costos a crecer). Durante este perodo se utilizaba en la mayora de los sistemas una orientacin por lotes. Algunas excepciones fueron sistemas interactivos (Sistema de reservas de Amrica Airlines) y sistemas de tiempo real para la defensa (SAGE). No obstante esto, la mayor parte del hardware se dedicaba a la ejecucin de un nico programa que, a su vez, se dedicaba a una aplicacin especfica. Lo normal era que el hardware fuera de propsito general. Por otra parte, el software se diseaba a medida para cada aplicacin y tena una distribucin relativamente pequea. La mayora del software se desarrollaba y era utilizado por la misma persona u organizacin. La misma persona lo escriba, lo ejecutaba y, si fallaba, lo depuraba. Debido a este entorno personalizado del software, el diseo era un proceso implcito, realizado en la mente de alguien, y la documentacin normalmente no exista. La segunda era en la evolucin de los sistemas de computadoras se extiende desde la mitad de la dcada de los 60 hasta finales de los setenta. La multiprogramacin y los sistemas multiusuarios introdujeron nuevos conceptos de interaccin hombre mquina. Las tcnicas interactivas abrieron un nuevo mundo de aplicaciones y nuevos niveles de sofisticacin del hardware y del software. Los sistemas de tiempo real podan recoger, analizar y transformar datos de mltiples fuentes, controlando as los procesos y produciendo salidas en milisegundos en lugar de en minutos. Los avances en los dispositivos de almacenamiento en lnea condujeron a la primera generacin de sistemas de gestin de bases de datos. Otra caracterstica fue el establecimiento del software como producto y la llegada de las casas de software. Conforme creca el nmero de sistemas, comenzaron a extenderse las bibliotecas de software de computadora. Se desarrollaban proyectos en los que se producan programas de decenas de miles de sentencias fuente. Todos esos programas (todas esas sentencias fuentes) tenan que ser corregidos cuando se detectaban fallos, modificados cuando cambiaban los requisitos de los usuarios o adaptados a nuevos dispositivos que se hubieran incorporado. Estas actividades se llamaron mantenimiento del software. El esfuerzo gastado en el mantenimiento comenz a absorber recursos en una medida alarmante. Haba comenzado una crisis del software. La tercera era en la evolucin de los sistemas de computadoras comenz a mediado de los setenta y llega hasta el momento actual. El procesamiento distribuido (mltiples computadoras, cada una ejecutando funciones concurrentemente y comunicndose con alguna otra) increment notablemente la complejidad de los sistemas informticos. Las redes de rea local y de rea global, las comunicaciones digitales de alto ancho de banda y la creciente demanda de acceso instantneo a los datos, pusieron una fuerte presin sobre los desarrolladores del software. En esta era se produce la llegada de los microprocesadores y las computadoras personales.
7
Las computadoras personales han sido el catalizador del gran crecimiento de muchas compaas de software. Estas compaas venden decenas y centenares de copias de sus productos de software. La cuarta era del software de computadora est comenzando ahora. Las tecnologas orientadas a objetos estn comenzando a ser utilizadas en muchas reas de aplicacin. Las tcnicas de cuarta generacin para el desarrollo de software ya estn cambiando la forma en que algunos segmentos de la comunidad informtica construyen los programas. Los sistemas expertos y el software de inteligencia artificial se han trasladado del laboratorio a las aplicaciones prcticas. El software de redes neuronales artificiales ha abierto excitantes posibilidades para el reconocimiento de formas y habilidades de procesamiento de informacin al estilo de como lo hacen los humanos. Conforme transitamos por la cuarta era, continan intensificndose los problemas asociados con el software de computadoras: La sofisticacin del hardware ha dejado desfasada nuestra capacidad de construir software que pueda explotar el potencial del hardware. Nuestra capacidad de construir nuevos programas no puede dar abasto a la demanda de nuevos programas. Nuestra capacidad de mantener los programas existentes est amenazada por el mal diseo y el uso de recursos inadecuados.
7.2.- Los Principios Bsicos de la Ingeniera de Software.

En los primeros das de la informtica, la programacin se vea como un arte. Existan pocos mtodos formales, y pocas personas los usaban. El programador aprenda normalmente su oficio mediante prueba y error. Hoy, la distribucin de costos en el desarrollo de sistemas informticos ha cambiado drsticamente. El software, en lugar del hardware, es normalmente el elemento principal del costo. Los problemas existentes en el desarrollo de software no van a desaparecer rpidamente. Las soluciones que se van elaborando tienden a asistir prcticamente al desarrollador de software, y mejorar la calidad del software. Mediante la combinacin de mtodos completos para todas las fases de desarrollo de software, mejores herramientas para automatizar estos mtodos, bloques de construccin ms potentes para la implementacin del software, mejores tcnicas para la garanta de calidad del software y una filosofa predominante para la coordinacin, control y gestin, puede conseguirse una disciplina para el desarrollo del software : Ingeniera del software.
8.- EL PROCESO DE DISEO DEL SOFTWARE. 8.1.- Introduccin.

El diseo del software es un proceso mediante el que se traducen los requisitos en una representacin del software. Inicialmente, la representacin describe una visin holstica del software. Posteriores refinamientos conducen a una representacin de diseo que se acerca mucho al cdigo fuente. Durante el proceso de diseo tenemos presente los siguientes conceptos: Mtodos: Es una coleccin organizada de notaciones, tcnicas y procedimientos formales o semiformales para llevar a cabo una o ms de las principales actividades del ciclo de vida. El mtodo identificara las entregas y prescribe la forma o notacin en la que sern producidas. Mtodos diferentes a menudo comparten notaciones y tcnicas comunes. Clasificacin: Cuando los mtodos han sido identificados, el siguiente problema es la clasificacin para esto se emplean criterios, enfoques e investigaciones.
Visibilidad: Esta referido al sigilo que muchas organizaciones mantienen de su software y por tanto no brindan informacin acerca de su desarrollo. Exactitud: Se refiere al orden que debe regir el software, herramientas tcnicas para desarrollar el sistema.
9.- ARQUITECTURA, PATRONES DE DISEO Y REUSO. 9.1- Introduccin.

La Arquitectura del Software (AS) es la parte de la ingeniera del software que se ocupa de la descripcin y el tratamiento de un sistema como un conjunto de componentes, que facilite su organizacin en los diferentes subsistemas que lo forman. Esto es til, entre otras cosas, para poder asignarlos a equipos de trabajo y que puedan llevar a cabo el desarrollo del sistema de una manera organizada y eficiente. Esta disciplina surge ante la necesidad de describir sistemas de software complejos, descomponerlos en un conjunto de componentes y ver qu relaciones existen entre ellos. El objetivo de esta seccin es proporcionar una base de conocimiento mnima que sirva de apoyo. Para ello, se presenta un conjunto de definiciones de arquitectura del software propuestas por diversos autores. Igualmente, se hace un resumen de su evolucin histrica, desde los tiempos de Dijkstra, Parnas y Brooks, pasando por el nacimiento de esta disciplina, dnde fue denominada como tal (artculos de Perry y Wolf en 1989) y publicados ms tarde en 1992, hasta llegar a los conceptos ms recientes: estilos arquitectnicos, lenguajes de descripcin de arquitecturas y el concepto de vista arquitectnica, entre otros. Especificar la arquitectura de un sistema software en etapas tempranas del ciclo de vida tiene muchas ventajas segn la mayor parte de las metodologas de desarrollo del software actuales. La arquitectura del software puede definirse como el nivel del diseo del software en el que se definen tanto la estructura como las propiedades globales de un sistema, centrndose en aquellos aspectos del diseo y posterior desarrollo que no pueden tratarse adecuadamente dentro de los mdulos o componentes que lo forman. As pues, desde el punto de vista del proceso de desarrollo, la arquitectura del software se encarga de realizar el diseo preliminar o de alto nivel del sistema, de la organizacin del mismo, y de aspectos relacionados con su desarrollo y adaptacin al cambio (composicin, reconfiguracin y reutilizacin); y se despreocupa, por tanto, del diseo detallado, del diseo de algoritmos o del diseo de las estructuras de datos. Se trata de una organizacin de alto nivel del sistema software como una coleccin de componentes, conexiones entre dichos componentes y cmo estos interactan entre s; donde cada componente puede tomar decisiones acerca de los mensajes que enva a su entorno y reacciona cuando recibe de ese entorno un mensaje para el que est programado. Adems, la AS trata de la descripcin, verificacin y reutilizacin de los sistemas software. La descripcin de la arquitectura de los sistemas software adquiere gran importancia al aumentar su complejidad. Es por ello que, dado que las expectativas de los usuarios aumentan cada vez ms y la gestin de estos sistemas por parte de los diseadores se hace ms difcil, es necesario elegir una arquitectura adecuada para ellos, as como la posterior implementacin de cada una de las partes. Esta definicin arquitectnica es la que permitir gestionar los sistemas complejos, centrando su estudio en los componentes que lo forman y en las relaciones que se establecen entre ellos, de modo que, al final, estas partes componentes puedan trabajar conjuntamente para resolver el sistema. Creer que por conocer los requerimientos se puede construir la arquitectura de un sistema es un error. La arquitectura es el resultado de influencias tcnicas, de negocios y sociales. Tener una arquitectura real apoya el retorno de inversin con respecto a calidad, calendario y costo Software Architecture in Practice
9.2.- Definiciones
Aunque intuitivamente el concepto de AS es bastante claro, no se ha dado hasta el momento una definicin que satisfaga por completo a todos aquellos que trabajan en este campo. Quizs, para obtener una visin
9
de conjunto, lo ms adecuado sea considerar varias definiciones a la vez. A continuacin se mencionan varias de ellas ordenadas cronolgicamente: 9.2.1.- Primera definicin fue la dada en 1993 por David Garlan y Mary Shaw Ms all de los algoritmos y estructuras de datos de la computacin, el diseo y especificacin de la estructura global del sistema emerge como un nuevo tipo de problema. Los detalles estructurales incluyen: la organizacin general y la estructura de control global; los protocolos de comunicacin, sincronizacin y acceso a datos; la asignacin de funcionalidad a los elementos de diseo; la distribucin fsica; la composicin de los elementos de diseo; su escalabilidad y los aspectos de rendimiento; y la seleccin entre alternativas de diseo. 9.2.2.- Segunda definicin, dada en 1.995 por David Garlan y Dewayne Perry: La arquitectura del software est compuesta por la estructura de los componentes de un programa o sistema, sus interrelaciones, y los principios y reglas que gobiernan su diseo y evolucin a lo largo del tiempo. 9.2.3.- Definicin dada en 1.996 por Clements [Cle96] que puede La arquitectura del software es, a grandes rasgos, una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes segn se percibe desde el resto del sistema, y las formas en que los componentes interactan y se coordinan para alcanzar el objetivo del sistema. La vista arquitectnica es una vista abstracta de un sistema, aportando el ms alto nivel de compresin y la supresin del detalle inherente a la mayor parte de abstracciones. 9.2.4.- Definicin dada el ao 2000 en el documento IEEE. La arquitectura del software es la organizacin fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el entorno, y los principios que dirigen su diseo y evolucin. Si se compara esta definicin con la de Garlan y Perry, la de IEEE es ms precisa. 9.2.5.- Definicin dada en el ao 2006 por Kruchten, Obbink y Stafford en un artculo IEEE. La arquitectura del software captura y preserva las intenciones de los diseadores sobre la estructura y el comportamiento de los sistemas, proporcionando un mecanismo de defensa contra el deterioro de los sistemas antiguos. Esta es la clave para lograr el control intelectual sobre la creciente complejidad de los sistemas. Paradjicamente an no hay un consenso sobre cul es la respuesta a la pregunta de qu es la arquitectura del software y que sea ampliamente aceptada Llegar a un acuerdo sobre la definicin ms adecuada para esta disciplina fue uno de los objetivos de definir el estndar IEEE. Sin embargo, esta falta de acuerdo no ha sido impedimento para que la arquitectura del software progrese. A partir de todas las definiciones que se han dado sobre AS, se ha llegado a una especie de consenso por el que esta disciplina se refiere a la estructura de un sistema a grandes rasgos, formada por componentes y relaciones entre. Estas cuestiones se tienen en cuenta durante el diseo, puesto que la AS se refiere al diseo del software que se realiza en fases tempranas del desarrollo software y al alto nivel de abstraccin. Resumiendo se puede decir que la AS Permite realizar el diseo de alto nivel del sistema, definir su organizacin como la descripcin y anlisis de propiedades relativas a su estructura, los protocolos de comunicacin, su distribucin fsica y de sus componentes, etc., adems de los aspectos relacionados con el desarrollo del sistema y su adaptacin al cambio. Es decir, su composicin, reconfiguracin y reutilizacin. Por otra parte, la AS puede considerarse como un puente entre los requisitos y el cdigo: desempea un papel fundamental entre la especificacin de los requisitos de un sistema y la implementacin del mismo. Al realizar la descripcin abstracta del sistema se representan una serie de caractersticas, mientras otras se
10
ocultan, proporcionando as una gua para que los arquitectos o diseadores puedan sugerir un modelo de construccin en funcin de los requisitos. En esta seccin, recogiendo las definiciones anteriores, la AS se considera como Un conjunto formado por la organizacin, la estructura y la infraestructura de un sistema software. En este sentido, se describe un modelo arquitectnico para sistemas software, pudindose realizar una evaluacin y un anlisis del diseo obtenido. Adems, asociado al modelo se proporciona una descripcin lingstica formal del diseo. Por otra parte, el modelo arquitectnico que se propone ayuda a planificar y a gestionar la evolucin de los sistemas.
9.3.- Por Qu Reusar Software?

Responder a la demanda elevada Reducir esfuerzos de mantenimiento Reducir costos Mejorar la prctica de software
Incrementar la productividad Mejorar la calidad 9.4.- La Clave: Productividad .

Cambios en la estrategia de produccin
Uso de prototipos rpidos Uso de desarrollo incremental Compra de software hecho

Reus ayuda en todos estos aspectos
9.5.- Componentes Reusables

No slo cdigo. Incluye requerimientos, diseo, mtricas. Diseado para ser reutilizado Descripcin de especificacin y adaptabilidad Granularidad: tamao del componente
Probabilidad de reus inversamente proporcional Utilidad de reus directamente proporcional. 9.6.- Conclusiones.
La arquitectura del software nos proporciona una visin global del sistema a construir. Describe la estructura y la organizacin de los componentes del software, sus propiedades y las conexiones entre ellos. Los componentes del software incluyen mdulos de programas y varias representaciones de datos que son manipulados por el programa. Adems, el diseo de datos es una parte integral para la derivacin de la arquitectura del software.
11
La arquitectura marca decisiones de diseo tempranas y proporciona el mecanismo para evaluar los beneficios de las estructuras de sistema alternativas. El diseo de datos traduce los objetos de datos definidos en el modelo de anlisis, en estructuras de datos que residen dentro del software. Los atributos que describe el objeto, las relaciones entre los objetos de datos y su uso dentro del programa influyen en la eleccin de la estructura de datos. A mayor nivel de abstraccin, el diseo de datos conducir a lo que se define como una arquitectura para una base de datos o un almacn de datos. El ingeniero del software cuenta con diferentes estilos y patrones arquitectnicos. Cada estilo describe una categora de sistema que abarca un conjunto de componentes que realizan una funcin requerida por el sistema, un conjunto de conectores que posibilitan la comunicacin, la coordinacin y cooperacin entre los componentes, las restricciones que definen cmo se integran los componentes para conformar el sistema, y los modelos semnticos que facilitan al diseador el entendimiento de todas las partes del sistema. El diseo arquitectnico agrupa un grupo inicial de actividades de diseo que conducen a un modelo completo del diseo del software.
10.- ESTRATEGIAS DE DISEO DE SOFTWARE. 10.1.- Introduccin.

La gestin de sistemas complejos es uno de los retos que debe afrontar la Ingeniera del Software actual. Adems, el mundo real cambia y los sistemas deben adaptarse a l para seguir siendo tiles. Por esta razn, los ingenieros de software deben encontrar tcnicas y herramientas que le permitan adaptar los sistemas de manera sencilla.
10.2.- Diseo Orientado a la Funcin (Estructurado)

Es uno de los primeros paradigmas de diseo, que se centra en identificar las funciones principales de un sistema, y luego refinarlas en una manera top-down. El diseo estructurado se realiza despus del anlisis estructurado. Este anlisis produce DFDs con descripciones de procesos y tambin se pueden usar diagramas E-R Se han propuesto dos estrategias para derivar una arquitectura de software a partir de un DFD: Anlisis de transaccin: una transaccin se caracteriza por algn evento en el medio ambiente que genera un estmulo al sistema, quien a su vez gatilla alguna actividad que produce una respuesta teniendo un efecto hacia el medio ambiente. El anlisis de transacciones consiste en identificar los tipos de transacciones claves de un sistema y usarlos como unidades de diseo, esto es, diseando separadamente el procesamiento de cada tipo de transaccin. Anlisis de transformacin: el paso clave para derivar un diagrama de estructura de un DFD (para una transaccin dada) es identificar la transaccin central, esto es, la porcin de un DFD que contiene las funciones esenciales del sistema y es independiente de la implementacin de la entrada y salida. Una carta de estructura borrador se puede obtener elevando las burbujas asociadas a la transformacin central. Los conceptos claves del diseo estructurado son acoplamiento y cohesin. Un buen diseo debe restringir el acoplamiento a tipos normales de acoplamiento (datos, estampado, y control) siendo el de datos el preferido, donde la comunicacin entre mdulos es a travs de parmetros, donde cada parmetro es un pedazo de datos elemental, evitando as las formas patolgicas de acoplamientos, como la comn y de contenido.
12
Un buen diseo debe dar preferencia a mdulos de alta cohesin, es decir, mdulos que exhiban cohesin funcional, que es cuando el mdulo contiene todos los elementos que contribuyen a la ejecucin de una y slo una tarea relacionada al problema. Existen otras formas de cohesin ms dbiles se han identificado: secuencial, comunicacional, procedural, temporal, lgica y coincidental. Otras heursticas se han sugerido para ayudar a mejorar la calidad del diseo resultante: Fan-in/fan-out: un alto fan-in (nmero de mdulos que llaman a un mdulo M) es considerado bueno, ya que indica el reus de M. Por su parte un bajo o moderado fan-out (nmero de mdulos que M invoca) -mximo 5 a 7- es preferible. Particionamiento de decisiones: se debe evitar la divisin de decisiones, que ocurren cuando el reconocimiento de una condicin y la ejecucin de la accin asociada no se mantienen dentro del mismo mdulo. Sistemas balanceados: se prefiere un sistema balanceado, es decir, cuando los mdulos de alto nivel tratan con la lgica y datos abstractos (datos limpios y vlidos, independientes del formato de implementacin)
10.3.- Diseo Orientado a Objeto.

10.3.1.- Definicin. El diseo orientado a los objetos (DOO), al igual que otras metodologas de diseo orientadas a la informacin, crea una representacin del campo del problema del mundo real y hace corresponder con el mbito de la solucin que es el software. A diferencia de otros mtodos, el DOO produce un diseo que interconecta objetos de datos (elementos de datos) y operaciones en procesamiento en una forma que modulariza la informacin y el procesamiento, en lugar de dejar aparte el procesamiento. La naturaleza nica del diseo orientado a los objetos queda reflejada en su capacidad de construir sobre tres pilares conceptuales importantes del diseo de software: abstraccin, ocultamiento de informacin y modularidad. Todos los mtodos de diseo intenta desarrollar software con esas tres caractersticas fundamentales, pero slo el DOO proporciona un mecanismo que permite al diseador conseguir las tres sin complejidad ni necesidad de compromisos. Los objetos y las operaciones no son conceptos nuevos de programacin, pero el diseo orientado a los objetos si lo es. 10.3.2.- Orgenes del Diseo Orientado a Objetos. Durante los aos ochenta, la rpida evolucin de los lenguajes de programacin Smalltalk y Ada, seguida de un crecimiento explosivo del uso de los dialectos orientados a los objetos de C como C++ y Objevtive-C. Produjeron un inters inusitado en el DOO. En un temprano tratamiento de los mtodos para conseguir el diseo orientado a los objetos. Abbott [ABB83] mostr cmo el anlisis de la descripcin del problema y su solucin en el lenguaje natural se podr usar como gua para el desarrollo de la parte visible de un paquete. Un paquete contiene tantos datos como los procedimientos que operan sobre ellos. A finales de los ochenta. El DOO se usaba en el diseo de aplicaciones de software que iban desde las animaciones grficas en computadora hasta las telecomunicaciones. Actualmente, muchos creen que con la llegada del nuevo milenio, los mtodos y los lenguajes de programacin orientados a los objetos sern los que predominen. 10.3.3.- Conceptos del DOO. Al igual que otros mtodos de diseo, El DOO introduce un nuevo conjunto de trminos, notaciones y procedimientos para la derivacin del diseo del software en esta seccin repasamos la terminologa orientada a los objetos e introducimos algunos conceptos adicionales que son relevantes para el diseo.
13
Para juzgar la capacidad de un mtodo de diseo de conseguir la modularidad y los relaciona con el diseo orientado a los objetos: Descomponibilidad: la facilidad con que un mtodo de diseo ayuda al diseador a descomponer un gran problema en subproblemas ms fciles de resolver.
Componibilidad: el grado en que un mtodo asegura que las componentes del programa (mdulos),
una vez diseadas y construidas pueden ser reusadas para crear otros programas
Comprensibilidad: la facilidad con que se puede comprender una componente de un programa sin
tener que referenciar otra informacin ni otros mdulos Continuidad: la capacidad de realizar pequeos cambios en un programa a y esos cambios se manifiestan por s mismos con solo unos cambios correspondientes en uno o unos pocos mdulos. Proteccin: una caracterstica arquitectnica que reduce la propagacin de
10.4.- Diseo Orientado a la Estructura de Datos.

10.4.1.- Introduccin. Hemos ya observado que el dominio de la informacin para un problema de software comprende el flujo de datos, el contenido de datos y la estructura de datos. Los mtodos de anlisis orientados a la estructura de datos representan los requerimientos del software enfocndose hacia la estructura de datos en vez de al flujo de datos. Aunque cada mtodo orientado a la estructura de datos tiene un enfoque y notacin distinta, todos tienen algunas caractersticas en comn:
Todos asisten al analista en la identificacin de los objetos de informacin clave (tambin llamados
entidades o tems) y operaciones (tambin llamadas acciones o procesos);
Todos suponen que la estructura de la informacin es jerrquica; Todos requiere que la estructura de datos se represente usando la secuencia, seleccin y
repeticin; y
Todos dan un conjunto de pasos para transformar una estructura de datos jerrquica en una
estructura de programa. Como los mtodos orientados al flujo de datos, los mtodos de anlisis orientados a la estructura de datos proporcionan la base para el diseo de software. Siempre puede extenderse un mtodo de anlisis para que abarque el diseo arquitectural y procedimental del software. Esta estrategia de diseo se conoce como programacin estructurada de Jackson. El nfasis se basa en los datos que manipula el programa en vez de las funciones que realiza. El nfasis se basa en que los datos son ms estables (menos sujetos a cambios) que las funciones que debe desarrollar. El diseador describe los datos de entrada y salida, usando los diagramas de estructura de Jackson, y desarrolla entonces la estructura de control del programa estableciendo una correspondencia apropiada entre los diagramas de estructura de entrada y salida. 10.4.2.- Desarrollo de Sistemas de Jackson
El desarrollo de sistema de Jackson (DSJ) se obtuvo a partir del trabajo de M.A. Jackson sobre el anlisis del dominio de la informacin y sus relaciones con el diseo de programas y sistemas. En palabras de Jackson: El que desarrolla el software comienza creando un modelo de la realidad a la que se refiere el sistema, la realidad que proporciona su materia objeto [del sistema]... Para construir un DSJ el analista aplica los siguientes pasos:
14
Paso de las acciones y entidades. Usando un mtodo muy similar a la tcnica de anlisis orientada al objeto, en este paso se identifican las entidades (persona, objetos u organizaciones que necesita un sistema para producir o usar informacin) y acciones (los sucesos que ocurren en el mudo real que afectan a las entidades). Paso de estructuracin de las entidades. Las acciones que afectan a cada entidad son ordenadas en el tiempo y representadas mediante diagramas de Jackson (una notacin similar a un rbol). Paso de modelacin inicial. Las entidades y acciones se representan como un modelo del proceso; se definen las conexiones entre el modelo y el mundo real. Paso de las funciones. Se especifican las funciones que corresponden a las acciones definidas. Paso de temporizacin del sistema. Se caractersticas de planificacin del proceso. establecen y especifican las
Paso de implementacin. Se especifica el hardware y software como un diseo. Los ltimos tres pasos del DSJ estn muy relacionados con el diseo de sistemas. 10.5.- Diseo Orientado Aspectos.
10.5.1.- Introduccin. El diseo de software orientado a aspectos (DSOA) es un paradigma en auge que se est convirtiendo en una alternativa para mejorar el desarrollo de sistemas complejos. Primero, surgi la Programacin Orientada Aspectos (OA), centrada en la fase de implementacin y, posteriormente, se plante el desarrollo de sistemas OA, que propone la utilizacin del concepto de aspecto a lo largo de todo el ciclo de vida. As, los aspectos identificados en la ingeniera de requisitos o la especificacin y el anlisis se utilizan en el diseo o la implementacin. Esta aproximacin proporciona tcnicas para la identificacin y separacin de los aspectos, as como su composicin posterior. Igualmente permite identificar los que son concerns aspectuales y los que no lo son, concretamente durante las fases tempranas del desarrollo. Adems, permiten mantener la trazabilidad de tales concerns (materias de inters) en etapas posteriores. De este modo, se consigue una mejora en la modularizacin de los sistemas, obtenindose un cdigo menos enmaraado y evitndose la mezcla entre funcionalidad del sistema y los aspectos extra-funcionales, lo que, adems, facilita el mantenimiento y la evolucin. Para ello, las tcnicas para desarrollar sistemas OA amplan las tcnicas tradicionales, permitiendo la encapsulacin de los aspectos en mdulos independientes. Es decir, encapsulan las propiedades que atraviesan varios componentes de un sistema. 10.5.2.- Evolucin del DSOA El mantenimiento de los sistemas software ha sido un problema cuya resolucin ha interesado a los desarrolladores a lo largo de la historia de la informtica. Desde las conferencias de la OTAN en 1968, en las que se plante el problema del mantenimiento de los sistemas (surgiendo el trmino crisis del software), hasta hoy, se ha tratado de reducir el coste y el esfuerzo que supone el mantenimiento del software. Recientemente y dada la complejidad que van adquiriendo los sistemas a desarrollar, se ha hecho necesario dar a la evolucin del software un tratamiento ms cuidadoso, pues es un hecho que todos los sistemas estn sujetos a cambios. El uso de diversos paradigmas ha reducido dicho coste y ha permitido que la evolucin de los sistemas suponga la aplicacin de un menor esfuerzo.
15
Uno de los paradigmas que se ha utilizado para facilitar la evolucin de los sistemas y reducir su costo es el DSOA: la orientacin a aspectos aporta simplicidad al proceso de evolucin del software, ya que cuando se desea cambiar propiedades que afectan a un nico inters (concern) del producto software, slo habra que considerar las propiedades del aspecto que especifica el concern que cambia. Por eso, el DSOA, adems de proporcionar mecanismos para separar los diferentes aspectos o concerns del sistema durante el desarrollo software, se puede considerar como una aproximacin que permite afrontar de un modo diferente la resolucin de algunos de los problemas relativos a la evolucin del software. En este contexto, un aspecto se puede definir como: Un mecanismo de abstraccin que, de algn modo, se puede aadir a un sistema existente, de forma que el elemento incorporado no quede distribuido (disperso) entre varios mdulos del sistema, sino que se mantenga independiente de ellos. Tambin se podra decir que un aspecto (concern) puede ser: Cualquier criterio que permita separar partes de un sistema que tengan diferentes probabilidades de cambio o que tenga diferente impacto sobre la evolucin. De este modo, y dado que el paradigma del DSOA permite modelar como artefactos de software las propiedades que atraviesan los sistemas, los desarrolladores pueden adaptarlos ms fcilmente a los cambios y a la evolucin de estas propiedades, pues al modelarlas como aspectos (elementos independientes en el desarrollo) se pueden modificar (aadir, cambiar, eliminar) sin que los componentes del sistema resulten afectados. As, durante la evolucin, resulta sencillo incorporar nuevos elementos y los problemas de la adaptacin se resuelven ms fcilmente, frente a la utilizacin de paradigmas tradicionales en los que este cdigo transversal queda disperso por los diferentes mdulos o componentes del sistema.
16
BIBLIOGRAFIA:
I. II. III. IV. V. VI. VII. VIII.
http://es.scribd.com/doc/30537656/disenosoftware2 http://ocw.usal.es/ensenanzas-tecnicas/ingenieria-del-software/contenidos/Tema5Principiosdeldisenodelsoftware-1pp.pdf https://sites.google.com/a/tacs-utn.com.ar/tacsalumnos/Home/apuntes/orm http://es.wikipedia.org/wiki/Ingenier%C3%ADa_del_dise%C3%B1o http://dircompucv.ciens.ucv.ve/generador/sites/disist/archivos/clase1.pdf http://computacion.itam.mx/matingsoft/IngSW5Reuso.pdf http://www.slideshare.net/sifaqui/clase-2-484400 http://www.google.co.ve/search?as_q=estrategias+dise %C3%B1o+software+orientado+a+aspectos&as_epq=&as_oq=&as_eq=&hl=es&num=10&lr=&cr=& as_ft=i&as_filetype=&as_qdr=all&as_occt=any&as_dt=i&as_sitesearch=&as_rights=&safe=images& btnG=Buscar+con+Google http://www.wikilearning.com/curso_gratis/guia_del_desarrollo_de_software/3471-20
IX.
17

Unidad #1 Fundamentos de Diseño

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Unidad #1 Fundamentos de Diseño

Cargado por

Copyright:

Formatos disponibles

Repblica Bolivariana de Venezuela Universidad Politcnica del Oeste Mariscal Sucre

UNIDAD N 1 FUNDAMENTOS DE DISEO.

i.- Diseo. ii.- Codificacin. iii.- Prueba.

Para implementar los requisitos funcionales del sistema

Repblica Bolivariana de Venezuela Universidad Politcnica del Oeste Mariscal Sucre

1.3.- Diseo de Datos.

1.1.3.- Diseo Arquitectnico:

1.5.- Diseo Procedimental:

2.- IMPORTANCIA DEL DISEO DE SOFTWARE. 2.1.- Introduccin.

2.2.- Alcance del Diseo del Software.

3.- PERSISTENCIA Y ALMACENAMIENTO. 3.1.- Introduccin.

Repblica Bolivariana de Venezuela Universidad Politcnica del Oeste Mariscal Sucre

3.3.- Uso de Base de Datos Relacionales.

Repblica Bolivariana de Venezuela Universidad Politcnica del Oeste Mariscal Sucre

4.2.- Algunas Descripciones Estructurales (Vista Esttica).

4.3.- Algunas Descripciones Conductuales (Vista Dinmica)

4.4.- Documentacin de Diseo.

Repblica Bolivariana de Venezuela Universidad Politcnica del Oeste Mariscal Sucre

6.- DISEO DE ATRIBUTOS DE CALIDAD. 6.1.- Proceso y Calidad del Diseo.

Repblica Bolivariana de Venezuela Universidad Politcnica del Oeste Mariscal Sucre

Debe obtenerse el diseo mediante un modulo reproducible.

7.- EVOLUCION DEL DISEO DE SOFTWARE. 7.1.- Historia.

Repblica Bolivariana de Venezuela Universidad Politcnica del Oeste Mariscal Sucre

Los primeros aos

Orientacin por lotes Distribucin limitada Software a medida

Repblica Bolivariana de Venezuela Universidad Politcnica del Oeste Mariscal Sucre

7.2.- Los Principios Bsicos de la Ingeniera de Software.

8.- EL PROCESO DE DISEO DEL SOFTWARE. 8.1.- Introduccin.

Repblica Bolivariana de Venezuela Universidad Politcnica del Oeste Mariscal Sucre

9.- ARQUITECTURA, PATRONES DE DISEO Y REUSO. 9.1- Introduccin.

Repblica Bolivariana de Venezuela Universidad Politcnica del Oeste Mariscal Sucre

Repblica Bolivariana de Venezuela Universidad Politcnica del Oeste Mariscal Sucre

9.3.- Por Qu Reusar Software?

Incrementar la productividad Mejorar la calidad 9.4.- La Clave: Productividad .

Uso de prototipos rpidos Uso de desarrollo incremental Compra de software hecho

9.5.- Componentes Reusables

Repblica Bolivariana de Venezuela Universidad Politcnica del Oeste Mariscal Sucre

10.- ESTRATEGIAS DE DISEO DE SOFTWARE. 10.1.- Introduccin.

10.2.- Diseo Orientado a la Funcin (Estructurado)

Repblica Bolivariana de Venezuela Universidad Politcnica del Oeste Mariscal Sucre

10.3.- Diseo Orientado a Objeto.

Repblica Bolivariana de Venezuela Universidad Politcnica del Oeste Mariscal Sucre

10.4.- Diseo Orientado a la Estructura de Datos.

Repblica Bolivariana de Venezuela Universidad Politcnica del Oeste Mariscal Sucre

Repblica Bolivariana de Venezuela Universidad Politcnica del Oeste Mariscal Sucre

Repblica Bolivariana de Venezuela Universidad Politcnica del Oeste Mariscal Sucre

I. II. III. IV. V. VI. VII. VIII.

También podría gustarte