1.

- Anlisis de Requisitos
El anlisis de los requisitos genera la especificacin de caractersticas operacionales de software. Interfaz del software con otros elementos del sistema y establece las restricciones que tiene el software Permite al ingeniero de software construir elementos que representen escenarios del usuario, actividades funcionales, clases de problemas y sus relaciones. La especificacin de requisitos ofrecen al desarrollador y al cliente los medios para evaluar la calidad una vez construido el software.

1.1 Filosofa y objetivos generales

El modelo de anlisis debe cumplir tres objetivos primarios: 1. Describe lo que requiere el cliente 2. Establecer una base para la creacin de un diseo de software 3. Definir un conjunto de requisitos que puedan validarse una vez construido el software.

1.2 Reglas prcticas para el Modelado de Anlisis

El modelo debe centrarse en los requisitos visibles dentro del problema o dominio de negocio. Se debe minimizar el acoplamiento de todo el sistema Se debe tener la seguridad de que el modelo de anlisis proporciona valor a todos los interesados. El modelo debe mantenerse tan simple como sea posible.

1.3 Anlisis del Dominio

El anlisis del domino es encontrar o crear aquellas clases de anlisis o funciones y caractersticas comunes que se aplican ampliamente para que puedan reutilizarse. El papel del analista de dominio es descubrir y definir patrones de anlisis reutilizables, clases de anlisis e informacin relacionada que pueda usar mucha gente en aplicaciones parecidas.

2.- Enfoques de modelado de anlisis

Un enfoque del modelado de anlisis es el: Anlisis Estructurado: Los objetos de datos se modelan en una forma que define sus atributos y relaciones. Anlisis Orientado a Objetos: Se centra en la definicin de clases y en la manera en que stas colaboran entre ellas para efectuar los requisitos del sistema.

3.- Conceptos del modelado de datos

El modelado de datos es definir todos los objetos de datos que se procesan dentro del sistema y las relaciones entre los objetos de datos.

3.1 Objetos de datos

Es una representacin de casi cualquier informacin compuesta (se refiere a que tiene muchas propiedades o atributos) que el software debe entender. Ejemplo: un lugar, un auto, una persona.

3.2 Atributos
Los atributos definen las propiedades de un objeto de datos, se definen uno o ms atributos como un identificador, ste se convierte en una clave para identificar un registro. Ejemplo: cedula, nombre, edad, altura de una persona.

3.3 Relaciones
La relacin se refiere a establecer una conexin entre objetos. Ejemplo: persona posee auto ( posee es la relacin).

3.4 Cardinalidad
La cardinalidad establece el nmero de objetos que pueden participar en una relacin. Las relaciones pueden ser: De uno a uno De uno a muchos De muchos a muchos

4.- Anlisis Orientado a Objetos

Se refiere a definir todas las clases relevantes para el problema y que deben resolverse. Esto se logra llevando a cabo algunas tareas: 1.- Deben comunicarse los requisitos bsicos del usuario entre el cliente y el ingeniero de software. 2.- Deben identificarse las clases, es decir, definir los atributos y mtodos. 3.- Se define una jerarqua de clases. 4.- Deben representarse las relaciones de objeto a objeto. 5.- Debe modelarse el comportamiento del objeto. 6.- Las tareas 1 a 5 se vuelven a aplicar de manera iterativa hasta que el modelo est completo.

5.- Modelado basado en escenarios

El modelado de anlisis con UML comienza con la creacin de escenarios en la forma de casos de uso, diagramas de actividad y diagramas de carril. Diagrama de casos de uso : Un caso de uso especifica la manera en la que los actores interactan con el sistema en un conjunto especfico de circunstancias. El desarrollo de una serie de casos de uso se comienza haciendo una lista de las funciones o actividades que realiza un actor especfico.

5.1 Diagramas de Casos de Uso

Un caso de uso especifica la manera en la que los actores interactan con el sistema en un conjunto especfico de circunstancias. El desarrollo de una serie de casos de uso se comienza haciendo una lista de las funciones o actividades que realiza un actor especfico

5.2 Diagrama de Actividades

Complementa el caso de uso al proporcionar una representacin grafica del flujo de interaccin dentro de un escenario especfico.

5.3 Diagrama de Carril

Es una variacin til del diagrama de actividad, ya que permite al modelador la representacin del flujo de actividades descritas por el caso de uso y al mismo tiempo indicar que actor o clases de anlisis tiene la responsabilidad de la accin descrita mediante un rectngulo de actividad.

6.-Modelo orientado al flujo

Tiene una visin del sistema del tipo entrada-proceso-salida. Los objetos de datos fluyen hacia el interior del software, se transforman mediante elementos de procesamiento y los objetos de datos resultantes fluyen al exterior del software.

7.- Modelado basado en clases

Una clase orientada a objetos encapsula atributos de los datos pero tambin incorpora las operaciones que manipulan los datos implicados por dichos atributos. Las clases se manifiestan en la siguiente forma: entidades externas, sucesos o eventos, cosas, papeles o roles, unidades organizacionales, sitios y estructuras.

7.1 Representacin de una clase

Las clases se manifiestan en una de las siguientes formas: Entidades Externas: que producen o consumen informacin que usara un sistema basado en computadora (Ej. Personas, otros sistemas, dispositivos) Cosas que son parte del dominio de la informacin para el problema (Ej. Reportes, despliegues, letras, seales) Sucesos o eventos que ocurren dentro del contexto de la operacin del sistema (Ej. Transferencia de propiedad o movimientos de un robot) Papeles que desempean personas que interactan con el sistema (ej. Gerente, ingeniero, personal de ventas) Unidades organizacionales relevantes para alguna aplicacin (Ej.: divisin, grupo, equipo)

Sitios que establecen el contexto del problema y la funcin global del sistema (el piso de manufactura o el puerto de carga)

7.2 Especificacin de atributos

Describen una clase que ha sido seleccionada para incluirla en el modelo de anlisis. En consecuencia son los que definen la clase, lo cual clarifica que significa la clase en el contexto del espacio del problema. Ej.: CLIENTE Numero de cuenta, Cedula, Nombres Apellidos, Telfono, Direccin

7.3 definicin de operaciones

Definen el comportamiento de un objeto, estos se pueden dividir en tres grandes categoras 1.- operaciones que manipulan los datos de alguna manera ej. Agregar, borrar, reformatear, seleccionar 2.- operaciones que realizan un computo 3.- operaciones que preguntan acerca del estado de un objeto 4.- operaciones que monitorean un objeto para la ocurrencia de un evento

7.4 Modelo de Clase-Responsabilidad-Colaborador(CRC)

El modelado de Clase-Responsabilidad-Colaborador (CRC) proporciona un medio simple para identificar y organizar las clases relevantes para los requisitos del sistema o producto. Un modelo CRC es una coleccin de tarjetas ndices estndar que representan clases. El objeto es desarrollar una representacin organizada de las clases. Clases tienen diferentes categoras: Clases de entidad: llamadas clases de modelo o negocios, se extraen de manera directa del enunciado del problema. Clases de frontera: se utilizan para crear la interfaz que el usuario ve y con la cual interacta cuando se utiliza el software. Clases de controlador: manejan una unidad de trabajo desde el inicio hasta el final.gh Responsabilidades son los atributos y las operaciones relevantes para la clase. Colaboradores: son aquellas clases que se requieren para que una clase reciba la informacin necesaria para completar una responsabilidad. Agregacin: son las subclases que forman parte de una clase, se conectan a travs de una relacin de tipo es parte de.

7.5 Asociaciones y Dependencias

Son las relaciones entre clases. Dependencia: en el contexto de las clases va ligada a las operaciones, indicando que una clase utiliza otra como argumento en la signatura de una operacin.

8.-Modelo de Comportamiento
El modelo de comportamiento indica la forma en que el software responder a los eventos o estmulos externos. 1. Evaluar todos los casos de uso para entender por completo la secuencia de interaccin dentro el sistema 2. Identificar los eventos que conducen la secuencia de interaccion y entender la forma en que estos eventos se relacionan con las clases especificas 3. Crear una secuencia para casa caso de uso 4. Construir un diagrama de estado para el sistema 5. Revisar el modelo de comportamiento para verificar su exactitud y consistencia Diagrama de estado: Representa el comportamiento de las clases cuando el sistema realiza sus funciones. Diagrama de Secuencia: Representa el comportamiento al describir la forma en que las clases se mueven de estado a estado.

9. Diseo de software
El objetivo de los diseadores es producir un modelo o representacin de una entidad que se ser construida a posteriori, describe el proceso mediante el cual se desarrolla el modelo de diseo. La diversificacin y la convergencia combinan intuicin y juicio en funcin de la experiencia en construir entidades similares, un conjunto de principios y/o heurstica que proporcionan la forma de guiar la evolucin del modelo, un conjunto de criterios que posibilitan la calidad que se va a juzgar, y un proceso de iteracin que por ltimo conduce a una representacin final de diseo.

9.1 El proceso de diseo

El diseo del software es un proceso iterativo mediante el cual los requisitos se traducen en un plano para construir el software. Inicialmente, el plano representa una visin holstica del software. Esto es, el diseo se representa a un nivel alto de abstraccin un nivel que puede rastrearse directamente hasta conseguir el objetivo del sistema especfico y segn unos requisitos ms detallados de comportamiento, funcionales y de datos. A medida que ocurren las iteraciones del diseo, el refinamiento subsiguiente conduce a representaciones de diseo a niveles de abstraccin mucho ms bajos. Estos niveles se podrn rastrear an segn los requisitos, pero la conexin es ms sutil. 9.2 Diseo y calidad del software

A lo largo de todo el proceso del diseo, la calidad de la evolucin del diseo se evala con una serie de revisiones tcnicas formales o con las revisiones de diseo sugiere tres caractersticas que sirven como gua para la evaluacin de un buen diseo, el diseo deber implementar todos los requisitos explcitos del modelo de anlisis, y debern ajustarse a todos los requisitos implcitos que desea el cliente, el diseo deber ser una gua legible y comprensible para aquellos que generan cdigo y para aquellos que comprueban y consecuentemente, dan soporte al software. El diseo deber proporcionar una imagen completa del software, enfrentndose a los dominios de comportamiento, funcionales y de datos desde una perspectiva de implementacin. Con el fin de evaluar la calidad de una representacin de diseo, debern establecerse los criterios tcnicos para un buen diseo. Por ahora se presentarn las siguientes directrices: 1. Un diseo deber presentar una estructura arquitectnica que se haya creado mediante Patrones de diseo reconocibles, que est formada Por componentes que exhiban caractersticas de buen diseo y que se puedan implementar de manera evolutiva, facilitando as la implementacin y la comprobacin. 2. Un diseo deber ser modular; esto es, el software deber dividirse lgicamente en elementos que realicen funciones y subfunciones especficas. 3. Un diseo deber contener distintas representaciones de datos, arquitectura, interfaces y componentes (mdulos). 4. Un diseo deber conducir a estructuras de datos adcuadas para los objetos que se van a implementar y que procedan de patrones de datos reconocibles. 5. Un diseo deber conducir a componentes que presenten caractersticas funcionales independientes. 6. Un diseo deber conducir a interfaces que reduzcan la complejidad de las conexiones entre los modulos y con el entorno externo. 7. Un diseo deber derivarse mediante un mtodo repetitivo y controlado por la informacin obtenida durante el anlisis de los requisitos del software. Estos criterios no se consiguen por casualidad. El proceso de diseo del software fomenta el buen diseo a travs de la aplicacin de principios de diseo fundamentales, de metodologa sistemtica y de una revisin cuidadosa.

9.3 Conceptos del diseo

Durante las ltimas cuatro dcadas se ha experimentado la evolucin de un conjunto de conceptos fundamentales de diseo de software. Aunque el grado de inters en cada concepto ha variado con los aos, todos han experimentado el paso del tiempo. Cada uno de ellos proporcionar la base de donde el diseador podr aplicar los mtodos de diseo ms sofisticados. Cada uno ayudar al ingeniero del software a responder las preguntas siguientes: Qu criterios se podrn utilizar para la particin del software en componentes individuales?

Cmo se puede separar la funcin y la estructura de datos de una representacin conceptual del software? Existen criterios uniformes que definen la calidad tcnica de un diseo de software?

9.3.1 Abstraccin
Cuando se tiene en consideracin una solucin modular a cualquier problema, se pueden exponer muchos niveles de abstraccin. En el nivel ms alto de abstraccin, la solucin se pone como una medida extensa empleando el lenguaje del entorno del problema. En niveles inferiores de abstraccin, se toma una orientacin ms procedimental. La terminologa orientada a problemas va emparejada con la terminologa orientada a la implementacin en un esfuerzo por solucionar el problema. Finalmente, en el nivel ms bajo de abstraccin, se establece la solucin para poder implementarse directamente. Wasserman proporciona una definicin til: Cada paso del proceso del software es un refinamiento en el nivel de abstraccin de la solucin del software. Durante la ingeniera del sistema, el software se asigna como un elemento de un sistema basado en computadora. Durante el anlisis de los requisitos del software, la solucin del software se establece en estos trminos: aquellos que son familiares en el entorno del problema. A medida que nos adentramos en el proceso de diseo, se reduce el nivel de abstraccin. Finalmente el nivel de abstraccin ms bajo se alcanza cuando se genera el cdigo fuente.

9.3.2. Refinamiento
El refinamiento paso a paso es una estrategia de diseo descendente propuesta originalmente por Niklaus Wirth. El desarrollo de un programa se realiza refinando sucesivamente los niveles de detalle procedimentales. Una jerarqua se desarrolla descomponiendo una sentencia macroscpica de funcin (una abstraccin procedimental) paso a paso hasta alcanzar las sentencias del lenguaje de programacin. El refinamiento verdaderamente es un proceso de elaboracin. Se comienza con una sentencia de funcin(o descripcin de informacin) que se define a un nivel alto de abstraccin. Esto es, la sentencia describe la funcin o informacin conceptualmente, pero no proporciona informacin sobre el funcionamiento interno de la informacin. El refinamiento hace que el diseador trabaje sobre la sentencia original, proporcionando cada vez ms detalles a medida que van teniendo lugar sucesivamente todos y cada uno de los refinamientos.

9.3.3. Modularidad
El concepto de modularidad se ha ido exponiendo desde hace casi cinco dcadas en el software de computadora. La arquitectura de computadora expresa la modularidad; es decir, el software se divide en componentes nombrados y abordados por separado, llamados frecuentemente mdulos, que se integran para satisfacer los requisitos del problema. Se ha afirmado que <<la modularidad es el nico atributo del software que permite gestionar un programa intelectualmente. El software monoltico (es decir, un programa

grande formado por un nico mdulo) no puede ser entendido fcilmente por el lector. La cantidad de rutas de control, la amplitud de referencias, la cantidad de variables y la complejidad global har que el entendimiento est muy cerca de ser imposible.

9.3.4. Arquitectura del software

La arquitectura del software alude a la estructura global del software y a las formas en que la estructura proporciona la integridad conceptual de un sistema. En su forma ms simple, la arquitectura es la estructura jerrquica de los componentes del programa (mdulos), la manera en que los componentes interactan y la estructura de datos que van a utilizar los componentes. Sin embargo, en un sentido ms amplio, los componentes se pueden generalizar para representar los elementos principales del sistema y sus interacciones. Un objetivo del diseo del software es derivar una representacin arquitectnica de un sistema. Esta representacin sirve como marco de trabajo desde donde se llevan a cabo actividades de diseo ms detalladas. Un conjunto de patrones arquitectnicos permiten que el ingeniero del software reutilice los conceptos a nivel de diseo. Propiedades estructurales. Este aspecto de la representacin del diseo arquitectnico define los componentes de un sistema (por ejemplo, mdulos, objetos, filtros) y la manera en que esos componentes se empaquetan e interactan unos con otros. Por ejemplo, los objetos se empaquetan para encapsular tanto los datos como el procesamiento que manipula los datos e interactan mediante la invocacin de mtodos. Familias de sistemas relacionados. El diseo arquitectnico deber dibujarse sobre patrones repetibles que se basen comnmente en el diseo de familias de sistemas similares. En esencia, el diseo deber tener la habilidad de volver a utilizar los bloques de construccin arquitectnicos.

9.3.5. Jerarqua de control

La jerarqua de control, denominada tambin estructura de programa, representa la organizacin de los componentes de programa (mdulos) e implica una jerarqua de control. No representa los aspectos procedimentales del software, ni se puede aplicar necesariamente a todos los estilos arquitectnicos. Para representar la jerarqua control de aquellos estilos arquitectnicos que se avienen a la representacin se utiliza un conjunto de notaciones diferentes. El diagrama ms comn es el de forma de rbol que representa el control jerrquico para las arquitecturas de llamada y de retorno. Sin embargo, otras notaciones, tales como los diagramas de Warnier-Orr y Jackson tambin se pueden utilizar con igual efectividad. Con objeto de facilitar estudios posteriores de estructura, definiremos una serie de medidas y trminos simples. Segn la Figura 13.3, la profundidad y la anchura proporcionan una indicacin de la cantidad de niveles de control y el mbito de control global, respectivamente. El grado de salida es una medida del nmero de mdulos que se controlan directamente con otro mdulo. El grado de entrada indica la cantidad de mdulos que controlan directamente un mdulo dado.

9.3.6. Divisin estructural

Si el estilo arquitectnico de un sistema es jerrquico, la estructura del programa se puede dividir tanto horizontal como verticalmente. En la Figura 13.4.a la particin horizontal define ramas separadas de la jerarqua modular para cada funcin principal del programa. Lo mdulos de control, representados con un sombreado ms oscuro se utilizan para coordinar la comunicacin entre ellos y la ejecucin de las funciones. El enfoque ms simple de la divisin horizontal define tres particiones -entrada, transformacin de datos (frecuentemente llamado procesamiento) y salida-. La divisin horizontal de la arquitectura proporciona diferentes ventajas: *proporciona software ms fcil de probar *conduce a un software ms fcil de mantener *propaga menos efectos secundarios * proporciona software ms fcil de ampliar

9.3.7. Estructura de datos

La estructura de datos es una representacin de la relacin lgica entre elementos individuales de datos. Como la estructura de la informacin afectar invariablemente al diseo procedimental final, la estructura de datos es tan importante como la estructura de programa para la representacin de la arquitectura del software.

9.4 Procedimiento de software

La estructura de programa define la jerarqua de control sin tener en consideracin la secuencia de proceso y de decisiones. El procedimiento de software se centra en el procesamiento de cada mdulo individualmente. El procedimiento debe proporcionar una especificacin precisa de procesamiento, incluyendo la secuencia de sucesos, los puntos de decisin exactos, las operaciones repetitivas e incluso la estructura/organizacin de datos.

Existe, por supuesto, una relacin entre la estructura y el procedimiento. El procesamiento indicado para cada mdulo debe incluir una referencia a todos los mdulos subordinados al mdulo que se est describiendo. Es decir, una representacin procedimental del software se distribuye en capas.

9.5 Ocultacin de informacin

El concepto de modularidad conduce a todos los diseadores de software a formularse una pregunta importante: Cmo se puede descomponer una solucin de software para obtener el mejor conjunto de mdulos?. El principio de ocultacin de informacin sugiere que los mdulos se caracterizan por las decisiones de diseo que (cada uno) oculta al otro. En otras palabras, los mdulos debern especificarse y disearse de manera que la informacin (procedimiento y datos) que est dentro de un mdulo sea inaccesible a otros mdulos que no necesiten esa informacin. Ocultacin significa que se puede conseguir una modularidad efectiva definiendo un conjunto de mdulos independientes que se comunican entre s intercambiando slo la informacin necesaria para lograr la funcin del software. La abstraccin ayuda a definir las entidades (o informacin).

9.6 Diseo arquitectnico

El diseo arquitectnico representa la estructura de los datos y los componentes Diseo de datos El conjunto de informacin almacenada en las diferentes bases de datos y reorganizada en el almacn de datos facilita la mi niera de datos 9.7 Diseo de la interfaz de usuario

Es un medio de comunicacin entre el hombre y mquina. Las reglas de oro

1. Dar el control al usuario Tener en consideracin una interaccin flexible. Ocultar al usuario ocasional los entresijos tcnicos. Disear la interaccin directa con los objetos que aparecen en la pantalla.

2. Reducir la carga de memoria del usuario Establecer valores por defecto tiles. Definir las deficiencias que sean intuitivas y mantener la consistencia en toda la familia de aplicaciones. Desglosar la informacin de forma progresiva.

3. Construir una interfaz consecuente Permitir que el usuario realice una tarea en el contexto adecuado. Mantener la consistencia en toda la familia de aplicaciones.

9.8 Diseo de componentes

El diseo consiste en convertir del diseo de datos, interfaces y arquitectura en un software operacional. El diseo a nivel de componentes establece los datos algortmicos que se requieren para manipular las estructuras de datos, efectuar la comunicacin entre los componentes del software por medio de las interfaces.