Qué Es Análisis y Diseño Orientado A Objetos
Qué Es Análisis y Diseño Orientado A Objetos
Qué Es Análisis y Diseño Orientado A Objetos
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
05/02/2013
Pgina 1
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.
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
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
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
Pgina 9
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.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
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
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
Se representa como una lnea entre clases con un nombre de asociacin. La asociacin es inherentemente bidireccional.
Pgina 19
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
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