NOMBRE DEL TRABAJO TEMA UNIDAD 1 ARQUITECTURA Y DISEO DE SOFTWARE

MATERIA ARQUITECTURA Y DISEO DE SOFTWARE

Catedrtico M.I. JOSE JAHVEH CONTRERAS DE LOS REYES Alumnos ANGEL GARCIA LOMAS ALEJANDRA DEL C. NARANJOS ROMAN ITZEL SALINAS RODRIGUEZ Carrera INGENIERIA EN SISTEMAS COMPUTACIONALES SEMESTRE OCTAVO

CD. ACUA, COAHUILA, MXICO

05/02/2013

Pgina 1

1.1Qu es Anlisis y Diseo Orientado a Objetos

Es un enfoque de la ingeniera de software que modela un sistema como un grupo de objetos que interactan entre s.En este mtodo de anlisis y diseo se crea un conjunto de modelos utilizando una notacin es decir un lenguaje unificado de modelado (UML) ADOO aplica tcnicas de modelado de objetos para analizar los requerimientos y para disear una solucin para mejorar los procesos involucrados

1.2 Referencias histricas.

Cada vez que se narra la historia de la arquitectura de software (o de la ingeniera de software, segn el caso), se reconoce que en un principio, hacia 1968, Edsger Dijkstra, de la Universidad Tecnolgica de Eindhoven en Holanda y Premio Turing 1972, propuso que se establezca una estructuracin correcta de los sistemas de software antes de lanzarse a programar, escribiendo cdigo de cualquier manera.

En 1969 Fred Brooks Jr y Ken Iverson llamaban arquitectura a la estructura conceptual de un sistema en la perspectiva del programador.

En 1971, C. R. Spooner titul uno de sus ensayos Una arquitectura de software para los 70s,

En 1972, Parnas public un ensayo en el que discuta la forma en que la modularidad en el diseo de sistemas poda mejorar la flexibilidad y el control conceptual del sistema, acortando los tiempos de desarrollo. En 1975, Brooks, diseador del sistema operativo OS/360 y Premio Turing 2000, utilizaba el concepto de arquitectura del sistema para designar la especificacin completa y detallada de la interfaz de usuario

la dcada de 1980, los mtodos de desarrollo estructurado demostraron no escalar suficientemente y fueron dejando el lugar a un nuevo paradigma, el de la programacin orientada a objetos.

Pgina 2

la dcada de 1990 fue sin duda la de la consolidacin y diseminacin de la AS en una escala sin precedentes.

Uno de los acontecimientos arquitectnicos ms importantes del ao 2000 fue la hoy clebre tesis de Roy Fielding que present el modelo REST, el cual establece definitivamente el tema de las tecnologas de Internet y los modelos orientados a servicios.

1.2.1 OMT (Tcnica de Modelado de Objetos).

es una metodologa muy precisa y completa creada 1991 las faces que la conforman son anlisis: es una abstraccion resumida y precisa de lo que debe hacer el sistema deseado. diseo del sistema: el sistema se organisa en subsistemas basandose en el analisis como de su arquitectura. diseo de objetos: se centra en la estructura de datos y algoritmos que son necesarios para implementar en cada clase . implementacin: las clases y objetos desarrolladas en la etapa de anlisis para ser im plementadas y el sistemas sea flexible y extensible con el diseo de este. este emplea tres clases de modelo: modelo de objetos modelo dinamico modelo funcional

se acopla a las necesidades de ingenieria actuales y maneja varios modelos lo que hace que esta metodologia se ha de las mas efiecientes.

Pgina 3

1.2.2 Metodologa Booch.

Booch en esencia plantea que para trabajar con su mtodo es conveniente trabajar en dos partes fundamentales: un microproceso y un macroproceso. Ambas partes incluyen varios pasos como son la identificacin de clases y objetos a un nivel de abstraccin, la identificacin de la semntica de esas clases y objetos, la identificacin de las relaciones entre esas clases y objetos, la seleccin de la estructura de datos y algoritmos para la implantacin de estas clases y objetos, la conceptualizacin del sistema, etc.

El microproceso de desarrollo del AOO de Booch incluye: Identificacin de clases y objetos. Proposicin de objetos candidatos. Conduccin del anlisis de comportamiento. Identificacin de escenarios relevantes. Definicin de atributos y operaciones para cada clase. Identificacin de la semntica de clases y objetos. Seleccin y anlisis de escenarios. Asignacin de responsabilidades para alcanzar el comportamiento deseado. Divisin de las responsabilidades para equilibrar el comportamiento. Seleccin de un objeto y enumerar sus papeles y responsabilidades. Definicin de operaciones para satisfacer las responsabilidades. Bsqueda de colaboraciones entre objetos. Identificacin de interrelaciones entre clases y objetos. Definicin de las dependencias que existen entre objetos. Descripcin del papel de cada objeto participante. Validacin de escenarios por revisin completa. Realizacin de una serie de refinamientos. Produccin de los diagramas apropiados para el trabajo realizado en las partes anteriores. Definicin de jerarquas de clases apropiadas. Creacin de agrupamientos basados en clases comunes. Implementacin de clases y objetos.

Pgina 4

1.3 METODO RUP (RATIONAL UNIFIED PROCESS)

Las siglas RUP en ingles significa Rational Unified Process (Proceso Unificado de Rational) es un producto del proceso de ingeniera de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organizacin del desarrollo. Su meta es asegurar la produccin del software de alta calidad que resuelve las necesidades de los usuarios dentro de un presupuesto y tiempo establecidos. Dimensiones del RUP El RUP tiene dos dimensiones: El eje horizontal representa tiempo y demuestra los aspectos del ciclo de vida del proceso. El eje vertical representa las disciplinas, que agrupan actividades definidas lgicamente por la naturaleza.

La primera dimensin representa el aspecto dinmico del proceso y se expresa en trminos de fases, de iteraciones, y la finalizacin de las fases. La segunda dimensin representa el aspecto esttico del proceso: cmo se describe en trminos de componentes de proceso, las disciplinas, las actividades, los flujos de trabajo, los artefactos, y los roles.

Pgina 5

Se puede hacer mencin de las tres caractersticas esenciales que definen al RUP:

Proceso Dirigido por los Casos de Uso: Con esto se refiere a la utilizacin de los Casos de Uso para el desenvolvimiento y desarrollo de las disciplinas con los artefactos, roles y actividades necesarias. Los Casos de Uso son la base para la implementacin de las fases y disciplinas del RUP. Un Caso de Uso es una secuencia de pasos a seguir para la realizacin de un fin o propsito, y se relaciona directamente con los requerimientos, ya que un Caso de Uso es la secuencia de pasos que conlleva la realizacin e implementacin de un Requerimiento planteado por el Cliente. Proceso Iterativo e Incremental: Es el modelo utilizado por RUP para el desarrollo de un proyecto de software. Este modelo plantea la implementacin del proyecto a realizar en Iteraciones, con lo cual se pueden definir objetivos por cumplir en cada iteracin y as poder ir completando todo el proyecto iteracin por iteracin, con lo cual se tienen varias ventajas, entre ellas se puede mencionar la de tener pequeos avances del proyectos que son entregables al cliente el cual puede probar mientras se esta desarrollando otra iteracin del proyecto, con lo cual el proyecto va creciendo hasta completarlo en su totalidad. Este proceso se explica mas adelante a detalle. Proceso Centrado en la Arquitectura: Define la Arquitectura de un sistema, y una arquitectura ejecutable construida como un prototipo evolutivo. Arquitectura de un sistema es la organizacin o estructura de sus partes ms relevantes. Una arquitectura ejecutable es una implementacin parcial del sistema, construida para demostrar algunas funciones y propiedades. RUP establece refinamientos sucesivos de una arquitectura ejecutable, construida como un prototipo evolutivo. Fases del mtodo RUP

Pgina 6

Planeando las fases El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce una nueva versin del producto, cada ciclo est compuesto por fases y cada una de estas fases est compuesta por un nmero de iteraciones, estas fases son: Concepcin Inicio o Estudio de oportunidad define el mbito y objetivos del proyecto se define la funcionalidad y capacidades del producto 2. Elaboracin Tanto la funcionalidad como el dominio del problema se estudian en profundidad se define una arquitectura bsica y se planifica el proyecto considerando recursos disponibles 3. Construccin El producto se desarrolla a travs de iteraciones donde cada iteracin involucra tareas de anlisis, diseo e implementacin. Las fases de estudio y anlisis slo dieron una arquitectura bsica que es aqu refinada de manera incremental conforme se construye (se permiten cambios en la estructura) Gran parte del trabajo es programacin y pruebas Se documenta tanto el sistema construido como el manejo del mismo esta fase proporciona un producto construido junto con la documentacin 4. Transicin Se libera el producto y se entrega al usuario para un uso real Se incluyen tareas de marketing, empaquetado atractivo, instalacin, configuracin, entrenamiento, soporte, mantenimiento, etc. Los manuales de usuario se completan y refinan con la informacin anterior estas tareas se realizan tambin en iteracionescada paso con las cuatro fases produce una generacin del software. Amenos que el producto "muera", se desarrollar nuevamente repitiendo la misma secuencia las fases de concepcin, elaboracin, construccin y transicin, pero con diversos nfasis cada fase.

Pgina 7

1.4 DISEO DE ALTO NIVEL (HLD) Y BAJO NIVEL (LLD)

DISEO DE BAJO NIVEL El diseo detallado es la actividad tcnica que sigue a la seleccin de la arquitectura. Es el ltimo paso en la descomposicin orientada a objetos, en el que se llega a las unidades de programacin: las clases de implementacin (representaciones simblicas del cdigo). Su objetivo es dejar el proyecto preparado para la implementacin/codificacin: parte de los resultados de la fase de arquitectura, describe en detalle cada una de las partes de la solucin, verifica que se satisfacen los requisitos, y produce un diseo completo y listo para ser programado. Un diseo completo gua suficientemente la implementacin, de modo que la hace comprensible y fcil de mantener, pero no necesariamente suprime toda creatividad en la implementacin. Es decir, los programadores deben ser capaces de implementar un diseo detallado, concentrndose en cuestiones de codificacin y dependientes de la plataforma tecnolgica (lenguaje de programacin, sistema operativo, hardware, etc.). Para que un diseo se pudiera implementar de forma no creativa, tendra que ser tan detallado que no sera prctico.

DISEO DE ALTO NIVEL

El diseo de alto nivel puede consistir de diagramas que expresen aspectos de las diferentes vistas de Kruchten, pero el diseo detallado es el cdigo fuente, punto. En software, nuestros planos detallados es un documento tcnico llamado comnmente cdigo fuente, dichos planos de nuestro producto son entregamos al constructor del producto: el compilador o traductor a cdigo ejecutable. El diseo de alto nivel establece el fondo, la forma y la interactividad del producto considerndolo como un todo, como un conjunto de pantallas homogneas que constituyen la estructura o arquitectura del producto multimedia sin entrar en el detalle de cada pantalla, ya que esto se har en el Diseo Detallado. El diseo de alto nivel establece la arquitectura general del producto por desarrollar. Este diseo toma como punto de partida los contenidos y estrategias definidas en la etapa de Diseo Instruccional y se enfoca en la descripcin de: Estilos visuales generales del producto y de las pantallas que lo componen. Elementos (texto, audio, imagen fija y en movimiento). Caractersticas estructurales y grficas del producto. Pgina 8

Navegacin entre las pantallas y otros aspectos relativos a la interactividad.

1.5 Comprensin de los requerimientos

Un requerimiento es una condicin o capacidad a la que el sistema (siendo construido) debe conformar [ Rational ]. Un requerimiento de software puede ser definido como : Una capacidad del software necesaria por el usuario para resolver un problema o alcanzar un objetivo. Una capacidad del software que debe ser reunida o poseda por un sistema o componente del sistema para satisfacer un contrato, especificacin, estndar, u otra documentacin formal. Los requerimientos de usuario representan el conjunto completo de resultados a ser obtenidos utilizando el sistema. Los requerimientos de sistemas deben mostrar todo lo que el sistema debe hacer mas todas las restricciones sobre la funcionalidad. Los requerimientos forman un modelo completo, representando el sistema total a algn nivel de abstraccin. IDENTIFICACION DE LOS REQUERIMIENTOS Los Requerimientos toman vida desde que realizamos nuestro primer encuentro de interlocucin con usuarios o clientes. Este puede desarrollarse utilizando cualquiera de una variedad de tcnicas como entrevistas para intercambiar opiniones, brainstorming , prototipeo,cuestionarios, etc. Cuando los requerimientos se logran redactar a un significativo nivel de detalle, tendremos listo el documento denominado Especificacin de Requerimientos ESPECIFICACION DE REQUERIMIENTOS Un resultado primario de esta administracin es la Especificacin de Requerimientos, la cual define y documenta en forma completa el comportamiento externo del sistema a ser construido. Caracterizndose por : Definidos sin ambiguedad Son completos

Pgina 9

 Tienen consistencia Especifica el origen Evita detalles de diseo Estn enumerados

BENEFICIOS DE UNA BUENA ADMISTRACION DE REQUERIMIENTOS Mejor control de proyectos complejos. Mejora en la calidad del software y en la satisfaccin del cliente. Reduccin en los retrasos y en los costos del proyecto. Mejora en la comunicacin del equipo. Facilita la conformidad con estndares y regulaciones. LOS PROBLEMAS DE LA ADMINISTRACION DE REQUERIMIENTOS No son siempre obvios y tienen muchas fuentes. No son siempre fciles de expresar en palabras. Hay muchos tipos diferentes a distintos niveles de detalle. El nmero puede llegar a ser inmanejable. Estn relacionados a otros en una variedad de formas. Hay muchos interesados y partes responsables. Cambian. Pueden ser sensibles al tiempo. EL ALTO COSTO DE ERRORES EN LOS REQUERIMIENTOS

Hay fuertes evidencias que una efectiva administracin de requerimientos conducen los ahorros del proyecto integral. Las tres razones primarias para esto son : Costos de reparar errores en los requerimientos superan en mas de 10 veces a otros errores. Pgina 10

 Errores de requerimientos comprenden encima del 40% de todos los errores de un proyecto de software. Pequeos reducciones en el nmero de errores de requerimientos rinden grandes dividendos al evitar costos de re-trabajo y das de retraso.

1.6 CASOS DE USO

Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios. Un caso de uso es iniciado por un actor. A partir de ese momento, ese actor, junto con otros actores, intercambian datos o control con el sistema, participando de ese caso de uso.

1.6.1 INTRODUCCION

LOS CASOS DE USO SIRVEN: Capturar los requerimientos del sistema Para capturar el comportamiento deseado del sistema sin tener que especificar como se implementa ese comportamiento Como medio de comprensin del sistema para desarrolladores, usuarios finales y expertos del dominio Ayudan a validar la arquitectura y a verificar el sistema en el transcurso del desarrollo de este Expresin de un caso de usos Grficamente: los casos de uso se representan con un valo, con el nombre del caso en su interior. GERUNDIO + OBJETO O ENTIDAD DEL SISTEMA QUE ES AFECTADO POR EL CASO

El nombre del caso siempre est expresado desde el punto de vista del actor y no desde el punto de vista del sistema. Por eso el segundo caso de uso se llama Recibiendo informacin de pedidos y no Generando informacin de pedidos

Pgina 11

1.6.2 Elementos de casos de uso (diagrama, Relaciones, Especificaciones, Identificacin de Casos de Uso).

ACTORES Un actor es una agrupacin uniforme de personas, sistemas o mquinas que interactan con el sistema que estamos construyendo de la misma forma. Los actores son externos al sistema que vamos a desarrollar. Si bien en UML los actores siempre se representan con hombres de palo, a veces resulta til representar a otros sistemas con alguna representacin ms clara.

Pgina 12

EJEMPLO DE UN ACTOR COMO SISTEMA

LOS CASOS DE USO TIENEN LAS SIGUIENTES CARACTERSTICAS: 1) Estn expresados desde el punto de vista del actor. 2) Se documentan con texto informal. 3) Describen tanto lo que hace el actor como lo que hace el sistema cuando interacta con l, aunque el nfasis est puesto en la interaccin. 4) Son iniciados por un nico actor. Descripcin de los Casos de Uso Los casos de uso se documentan con texto informal. En general, se usa una lista numerada de los pasos que sigue el actor para interactuar con el sistema. A continuacin se muestra una parte simplificada de la descripcin del caso de uso Ingresando Pedido.

Pgina 13

Alternativas Durante la ejecucin de un caso de uso, suelen aparecer errores o excepciones. Por ejemplo, mientras se ingresa un pedido, el cliente puede solicitar un producto que est discontinuado. El sistema deber en este caso informar esta situacin al empleado que ingresa el pedido. Esas desviaciones del curso normal del caso de uso se llaman alternativas. Las alternativas tienen las siguientes caractersticas: 1) Representan un error o excepcin en el curso normal del caso de uso. 2) No tienen sentido por s mismas, fuera del contexto del caso de uso en el que ocurren. las alternativas se documentan al final del caso de uso, la experiencia demuestra que resulta til documentar los casos en tablas, mostrando el curso principal en la primera columna, y las alternativas en una segunda columna Relaciones de Uso Las caractersticas de las relaciones de uso son: 1) Aparecen como funcionalidad comn, luego de haber especificado varios casos de uso. 2) Los casos usados son casos de uso en s mismos. 3) El caso es usado siempre que el caso que lo usa es ejecutado. Esto marca la diferencia con las extensiones, que son opcionales.

Pgina 14

1.7 Modelo del Dominio

Un modelo del dominio es una representacin de las clases conceptuales del mundo real, no de componentes software. No se trata de un conjunto de diagramas que describen clases software, u objetos software con responsabilidades. Tambin se les denomina modelos conceptuales (trmino utilizado en la primera edicin del libro de Larman), modelo de objetos del dominio y modelos de objetos de anlisis. Un modelo del dominio se utiliza con frecuencia como fuente de inspiracin para el diseo de los objetos software, y ser una entrada necesaria para varios de los siguientes artefactos que se vern en este curso. El modelo del dominio muestra (a los modeladores) clases conceptuales significativas en un dominio de] problema; es el artefacto ms importante que se crea durante el anlisis orientado a objetos. Modelos del Dominio Los modelos de dominio pueden mostrar: Objetos del dominio o clases conceptuales. Asociaciones entre las clases conceptuales. Atributos de las clases conceptuales.

Pgina 15

Idea clave: Modelo del dominio un diccionario visual de abstracciones. El modelo del ejemplo muestra una vista parcial, o abstraccin, e ignora detalles sin inters (para el modelador). Es fcil entender los distintos elementos y sus relaciones mediante este lenguaje visual, puesto que un porcentaje significativo del cerebro toma parte en el proceso visual cualidad de los humanos -. Por esto el modelo del dominio podra considerarse como un diccionario visual de abstracciones relevantes, vocabulario del dominio e informacin del dominio. Los modelos del dominio no son modelos de componentes de software Un modelo del dominio , es un representacin de las cosas del mundo real del dominio de inters, no de componentes del software. Por lo tanto, los siguientes elementos no son adecuados en un modelo de dominio: Artefactos de software, como una ventana o base de datos, a menos que el dominio que se este modelando sea de conceptos de software, como un modelo de interfaces de usuario grafica. Responsabilidades o mtodos Una clase conceptual es una idea, cosa u objeto. Ms formalmente, una clase conceptual podra considerarse en trminos de un smbolo, intencin, y extensin. Smbolo: palabras o imgenes que representan una clase conceptual. Intencin: la definicin de una clase conceptual. Extensin: el conjunto de ejemplos a los que se aplica la clase conceptual. Por ejemplo considerar la clase conceptual para el evento de una transaccin de compra.

Pgina 16

Cuando se crea un modelo del dominio, normalmente, el smbolo y la vista intencional de la clase conceptual son los que tienen un mayor inters prctico. La tarea central es identificar las clases conceptuales relacionadas con el escenario que se est diseado. Estrategias para identificar clases conceptuales: Utilizar una lista de categoras clases conceptuales. Identificacin de frases nominales. Otra excelente tcnica para el modelado del dominio es el uso de patrones de anlisis, que son modelos de dominios parciales existentes creados por expertos.

Pgina 17

Identificacin mediante frases nominales Otra tcnica til (debido a su simplicidad) recomendada es el anlisis lingstico: identificar los nombres y frases nominales en las descripciones textuales de un dominio, y considerarlos como clases conceptuales o atributos candidatos. Se debe tener cuidado con este mtodo; no es posible realizar una correspondencia mecnica de nombres a clases , y las palabras en lenguaje natural son ambiguas.

Pgina 18

1.7.2 Aadir asociaciones

Se representa como una lnea entre clases con un nombre de asociacin. La asociacin es inherentemente bidireccional.

Comience la inclusin de asociaciones utilizando la siguiente tabla

Pgina 19

Localizacin de las Asociaciones

Gua para las Asociaciones Centrase en aquellas asociaciones para las que se necesita conservar el conocimiento de la relacin durante el tiempo. Es ms importante identificar clases conceptuales que asociaciones. Pgina 20

Demasiadas asociaciones tienden a confundir el modelo. Evite mostrar asociaciones redundantes o derivadas Asociaciones en detalle Roles Los extremos de las asociaciones se denominan roles. Pueden tener opcionalmente Nombre, Expresiones de Multiplicidad, Navegabilidad. Multiplicidad Define cuantas instancias de una clase A pueden asociarse con una instancia de la clase B. * cero o ms muchos 1..* uno o ms 1..40 de uno a 40 5 exactamente 5 3,5,8 exactamente 3,5,8

Asignacin de nombres a las asociaciones Deben comenzar con mayscula. La direccin por defecto para la lectura de los nombres de la asociacin es de izquierda a derecha o de arriba a bajo. Asociacin e Implementacin Durante el modelo de dominio, una asociacin, es una manifestacin de que una relacin es significativa en un sentido puramente conceptual en el mundo real -. Se pueden definir asociaciones que no existan en la implementacin.

Pgina 21

1.7.3 Aadir atributos

Atributo es el valor de datos lgico de un objeto. Incluir los siguientes atributos en un modelo del dominio: aquellas para que los requisitos (ej: casos de uso) sugieran o impliquen una necesidad de registrar informacin.

Mantenga atributos simples Intuitivamente, la mayora de los atributos simples son los que, a menudo, se conocen como los tipos de datos primitivos, como los nmeros. El tipo de un atributo, normalmente no debera ser un concepto de dominio complejo, como Venta o Aeropuerto. Los atributos en un modelo de dominio deberan ser preferiblemente, atributos simples o tipos de datos (boolean, fecha, nmero, string, hora). Se recomienda que se relacionen las clases conceptuales por asociaciones no con atributos En caso de duda, defina algo como una clase conceptual aparte en lugar de como atributo.

Pgina 22