ANALISIS Y DISEÑO O.O. (LCD )

Slides:



Advertisements
Presentaciones similares
information technology service
Advertisements

Fundamentos de Diseño de Software INFT.1
FACHADA COMPOSITOR MEMENTO
Lenguaje Unificado de Modelado
Enfoques de desarrollo
ORACLE OLAP Integrantes: *Aizaga, Martiniano *Gallegos, Marina
Uso de patrones de arquitectura
UML 1.4 Peter Emerson Pinchao Solis.
El papel del analista de sistemas
Análisis Visual de la Modularidad de Modelos de Procesos de Software
DSOO - María Eugenia Valencia
Introducción 1 Puntos Clave –La orientación a objetos representa un cambio radical en los métodos tradicionales de creación de software –Los métodos tradicionales.
Prof. César Luza Montero
Ingeniería del Software
DIAGRAMAS DE INTERACCION JENNIFER COGOLLO CAMARGO CLAUDIA DIAZ MORELO ANDRES MACEA TIRADO CORPORACION UNIFICADA NACIONAL DE EDUCACION SUPERIOR - CUN.
Análisis y Diseño O.O. Click to add notes Preguntas del diseño :
Ingeniería de software Unidad II Ingeniería de Software Orientado a Objetos Principios Orientados a Objetos Tema Semana 7.
Ingeniería de Software Orientada a Objetos
 El termino OO, significa que el software es organizado como una colección de objetos. Un objeto es un paquete de software que contiene datos y procedimientos.
Contexto: Aplicación gráfica.  Siempre que se piensa en separar la funcionalidad de una aplicación de su interacción con el usuario, bien sea una aplicación.
TRABAJO GRASP Presentado por: Maria Paula Arias B. Luís Guillermo Torres R.
Patrones de asignación de responsabilidades (GRASP)
DS1 María E. Valencia Herencia La jerarquía de clases es un mecanismo a través del cual los cambios (a altos niveles) se pueden propagar inmediatamente.
(c) P. Gomez-Gil, INAOE DISEÑO DE COMPONENTES DE SOFTWARE * NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP.
1 LENGUAJES DE PROGRAMACIÓN Javier Martín Centro Asociado de Móstoles UNED.
ANDRES FELIPE BORRERO SALAZAR COD ALEXANDRA CARREÑO SALAS COD LUCIO ANIBAL CRIOLLO COD ALEJANDRO RUIZ IDROBO COD
DISEÑO DE SOFTWARE 1ª. Parte
Unidad 4 Diseño Arquitectónico Basado en la Funcionalidad
Patrones GRASP.
Presentado por Alfredo de la Mora Díaz Catedrático Dr. Jesús Favela
1 Diseño Orientado a Objetos Agustín J. González ELO-329: Diseño y Programación Orientados a Objetos 1er. Sem
Patrones para asignar responsabilidades
METODO DELPHI.
Control de errores visual basic
Son la base para la búsqueda de soluciones o problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.
INGENIERIA DE SOFTWARE GUILLERMO OCHOA GAVIRIA Octubre 2006 Factory Method.
Métricas Técnicas para Sistemas Orientados a Objeto
Spring Framework. Contenedor ligero de aplicaciones
SICSTRA Sistema de Información para el control de solicitudes de tramites jurídicos Ministerio de Justicia y Seguridad Pública.
Universidad Central de Venezuela Facultad de Ciencias Postgrado en Ciencias de la Computación Sistemas Distribuidos Albany Márquez.
SOFTWARE PARA PAGOS DE SUELDOS Patrones de Diseño
Modelo-Vista-Controlador Este patrón fue descrito por primera vez por Trygve Reenskaug en 1979, y la implementación original fue realizada en Smalltalk.
Ingeniería de software
Almudena Moya Muñoz Julio 2006 Una vuelta de tuerca a los principios de diseño ágiles.
Algoritmos y programación 3 - cátedra Fontela Diseñando mi solución en POO Eugenio Yolis - Marzo 2008.
Programación orientada a objetos Capítulo 6 Diseño de clases.
Desarrollo de Software Orientado a Objetos (deficiencias)
El modelo de análisis tiene como objetivo generar una arquitectura de objetos que sirva como base para el diseño posterior del sistema. Dependiendo del.
TEMA 9: DIAGRAMA DE CLASE EN UML
El rol de SQA en PIS.
Modelo de 3 capas.
Indirección y Variaciones Protegidas
ORACLE OLAP CAECE Integrantes: *Aizaga, Martiniano *Gallegos, Marina *Kleinlein, Guillermo *Schiano di Cola, Emiliano.
CONTRATOS DE CLIENTES Orlando Sedamano Cornejo Marco Bustinza
Roles de Open UP.
Diagrama de procesos.
Introducción al proceso de verificación y validación.
A RQUITECTURA DE SOFTWARE. CLIENTE-SERVIDOR Esta arquitectura consiste básicamente en un cliente que realiza peticiones a otro programa (el servidor)
1 Introducción a la Arquitectura de Sistema Maximiliano Déboli Director De Desarrollo MVP Azure Lagash
Gestión de proyectos fin de carrera
Mejores Prácticas para el Desarrollo de Software Omar de Jesús Rosales Hernández.
Acceso a Datos Erick López Ovando Licenciado en Informática.
Capas de ingeniería del Software. Rosendo Antonio Manuel Ingeniería en Sistemas Computacionales.
CICLO DE VIDA DE UN SOFTWARE. Es el conjunto de los programas de cómputo, procedimientos, reglas, documentación y datos asociados, que forman parte de.
Fundamentos de Ingeniería de Software
«ROLESDE LOS DIFERENTES ANALISTAS DE INFORMACIÓN.»
Roles de los diferentes análisis de información..
Engenharia de Software II
Ingeniería del Software Avanzada
Transcripción de la presentación:

ANALISIS Y DISEÑO O.O. (LCD 2006-1) Patrones GRASP ANALISIS Y DISEÑO O.O. (LCD 2006-1) base: Arquitectura de Software Julio Carreño / César Bustacara

Patrones GRASP

General Responsabilities Assignment Software Patterns

PATRONES Solución a Problemas recurrentes Capturar las Mejores Prácticas de Diseño NO son siempre la mejor solución Facilitan la comunicación BENEFICIOS Mantenibilidad Extensibilidad Reestructuración Portabilidad

CONOCER Información privada Objetos relacionados Lo que puede derivar/calcular Ej: Métodos analizadores "get"

HACER Algo él mismo Ejecutar un cálculo Crear un objeto Iniciar acciones en otros Objetos Controlar/Coordinar actividades en otros Objetos Ej: Métodos modificadores "set"

Experto

BENEFICIO Conserva el Encapsulamiento Bajo Acoplamiento Alta Cohesión

Ejemplo Asociaciones de Venta Calculo Total de la Venta Métodos a implementar

Ejemplo: Experto Asociaciones de Venta

Ejemplo: Experto Calculo Total de la Venta

Ejemplo: Experto Métodos a implementar

Creador

El Objeto B tiene la responsabilidad de tener un método para creación de objetos A si... B agrega objetos A B contiene objetos A B registra objetos A B usa exhaustivamente objetos A B posee info para iniciar A

BENEFICIO Bajo Acoplamiento

Ejemplo: Creador Agregar Items de Venta

Bajo Acoplamiento

¿Cómo soportar bajo grado de dependencia entre clases? Modelo DESCENTRALIZADO (ver dos objetos a lo mas!) Para clases que cambian constantemente... Para reutilización!

BENEFICIO No se afectan por cambios en otros componentes Fáciles de entender por separado Fáciles de reutilizar

Ejemplo: Bajo Acoplamiento Diseño Descentralizado Diseño Centralizado Propuesta Solución UNO Propuesta Solución DOS

Ejemplo: Bajo Acoplamiento Diseño Descentralizado

Ejemplo: Bajo Acoplamiento Diseño Centralizado

Ejemplo: Bajo Acoplamiento Propuesta Solución UNO

Ejemplo: Bajo Acoplamiento Propuesta Solución DOS

Alta Cohesión

BENEFICIO Mejoran la claridad del Diseño Simplificación del cambio Genera bajo acoplamiento Facilita la reutilización

Ejemplo Alta Cohesión Baja Cohesión

Ejemplo: Alta Cohesión

Ejemplo: Alta Cohesión Baja Cohesión

Controlador

Un coordinador... (por caso de uno!) Que representa el sistema: FACHADA! Que representa un rol activo: TAREAS! Un manejador artificial: SESSION!

BENEFICIO Mayor potencial de los Componentes reutilizables

Ejemplo Opciones de Controlador Solución Deseable No muy buena Solución

Ejemplo: Controlador Opciones de Controlador

Ejemplo: Controlador Solución Deseable

Ejemplo: Controlador No muy buena Solución

Fachada

Ejemplo Fachada

Patrones GRASP