Análisis y Diseño Orientado A Objetos (C-204)

Maestría en Ciencias de la Computación
Fundación Arturo Rosenblueth

Instructor:  J. Jesús María Zavala Ruiz

Introducción

Esta materia forma parte de la Maestría en Ciencias de la Computación, que a falta de una materia en Ingeniería de Software se le da un poco más el énfasis en esto. 

He de comentar también que esta materia es una materia donde no se necesitan prerrequisitos, más allá de la habilidad para leer, escribir y reflexionar sobre el proceso mismo del Análisis y Diseño de Sistemas de Información. 

Es de fundamental importancia que el alumno se esfuerse por leer los documentos que se sugieren como lecturas con el fin de que cuente con los elementos necesarios para la discusión previos a la clase y que realice las tareas para reforzar la comprensión de los temas tratados. 

Es una de las materias donde más que computadora se requiere imaginación y sentido común, ya que se hace mucho énfasis en retomar el famoso "Cut & Paste" original de cuando no existía la era digital, pero sobretodo en la capacidad de abstraer de los individuos.

También se recomenda ampliamente la consulta de la obra The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) de Frederick P. Brooks.

Mucho del material para el curso se encuentra en la Biblioteca Digital de la ACM, por lo que se sugiere a los alumnos que inviertan en uno de los mejores recursos de consulta en Ciencias de la Computación. Los Proceedings de la conferencia sobre el Futuro de la Ingeniería de Softweare del 2000 de la Conferencia Internacional en Ingeniería de Software (ICSE) (International Conference on Software Engineering,  Proceedings of the conference on The future of Software engineering 2000)

Estimado Alumno: ¡espero que lo distrutes y bienvenido (a)!

Lugares y Fechas

• Universidad Americana de Acapulco Acapulco, Gro. 22 de Noviembre al 7 de Diciembre del 2002

• Instituto Mexicano del Transporte. San Pedro Escobedo, Qro. 14 de Marzo al 5 de Abril del 2003

• Fundación Artuto Rosenblueth. Ciudad de México, D.F. 12 de Mayo al 14 de Agosto del 2003

Duración

42 horas

Objetivos

• Adquirirá una visión integral de las metodologías de diseño, el modelado y la instrumentación de sistemas con la orientación a objetos
• Aplicará la metodología de objetos en casos prácticos
• Adquirirá los conocimientos necesarios sobre los 3 niveles de modelado (modelos estático, dinámico y funcional) para llevar a cabo un buen proceso de análisis y diseño orientado a objetos

Programa

Temas y subtemas

1. Introducción al Paradigma Orientado a Objetos 

• Problemática Actual del Software
• Terminología y Conceptos Básicos
• Objetos y Clases
• Estructuras, Encapsulamiento, Mensajes, Protocolos y Métodos
• Jerarquías de Clases
• Herencia y Polimorfismo

2. Modelado Orientado a Objetos

• Modelo Estático:
  • Agregación
  • Generalización
  • Clases Abstractas
  • Herencia Múltiple
  • Diagramas de Clases
• Modelo Dinámico:
  • Sucesos y Estados
  • Diagramas de Estados
• Modelo Funcional
  • Diagramas de Flujo de Datos
• Introducción al Análisis Orientado a Objetos

3. Metodologías Orientadas a Objetos

• Análisis Comparativo de Metodologías
• Metodología OMT de Rumbaugh
• Metodología Ptech de Martin/Odell
• Metodología Objectory y OOSE
• Metodología OSA

4. Análisis Orientado a Objetos

• Análisis de la Estructura de los Objetos
• Estructura de los Objetos
• Funciones y Relaciones entre Objetos
• Clases abstractas y clases
• Análisis del Comportamiento de los Objetos
• Diagramas de Eventos
• Diagramas de Flujo de Objetos

5. Diseño Orientado a Objetos

• Diseño de la Estructura de los Objetos
• Tipos de Objetos
• Funciones básicas
• Jerarquía de Generalización
• Diseño del Comportamiento de los Objetos
• Operaciones
• Reglas de Activación
• Tipos de Eventos y sus Esquemas

Registro

• Se pide a los alumnos registrarse antes de iniciar el curso aquí. 

Bibliografía

• Booch, Grady (1997) Conducting a Software Architecture assessment Rational Software
• Booch, Grady (1997) Software as a Strategic Weapon Rational Software
• Booch, Grady  (1998) Architectural Patterns Rational Software
• Booch, Grady (2000) The Software Development Team Rational Software
• Conallen, Jim (2000) Modeling Web Application Architectures with UML™, Rational Software.
• Dave,West (2002) Planning a Project with the Rational Unified Process Rational Software
• Gamma, Helm, Johnson y Vlissides (1995) Design Patterns: Elements of Reusable Object-Oriented Software, 1st. ed., Addison Wesley Professional, 416 pag.
• Grahn,Goran V. y Karlsson, Boris (2002) Implementing RUP in an organization - The Volvo IT Approach Volvo Information Technology
• Kruchten, Philippe (1995). Architectural Blueprints - The "4+1" View Model of Software Architecture, Rational Software Corp.
• Kruchten, Philippe (1996) A Rational Development Process, Rational Software
• Kruchten, Philippe (2000) From Waterfall to Iterative Lifecycle - A tough transition for project manager Rational Software
• Jacobson, Ivar (1996) Ivar Jacobson's address at the OOPSLA ConferenceRational Software
  
• Jacobson, Ivar (1996) Ivar Jacobson's Object Expo Paris slide presentation: Reuse in Reality--The Reuse-Driven Software-Engineering Business Rational Software
  
• Jacobson, Ivar (2000). The Road to the Unified Software Development Process. Cambridge University Press and SIG Books. USA. Libro escrito por el creador del proceso. Trata sobre el origen, importancia y técnica del proceso de desarrollo de software y la utilización del UML
• Leffingwell, Dean (2000) Features, Use Cases, Requirements, Oh My! Rational US 
• Microsoft y Rational Software (1997) The Benefits of Integrating Microsoft Solutions Framework and the Rational Process Microsoft y Rational Software
• Microsoft. Microsoft Solutions Framework-Process Model. White paper sobre el proceso de desarrollo de software utilizado por Microsoft.
• Microsoft. Microsoft Solutions Framework-Team Model. White paper.sobre el modelo de equipos de trabajo y su organización para el desarrollo de software.
• Probasco, Leslee (2000) The Ten Essentials of RUP The Essence of an Effective Development Process Rational Software
• Rational (1996) The Key to Successful Automated Testing: Planning Rational Software, relevant 2002
• Rational (1998) Conceptual, Logical, and Physical design of Persistent Data using UML Rational Software
• Rational (2000) Mapping Object to Data Models with the UML Rational Software
• Rolf W. Reitzig, Carlo Rodriquez, and Gary Holt (2002) Achieving Capability Maturity Model Level 2 with the Rational Unified Process Cognence inc.,
  
• Rumbaugh, James (1994) OMT papers, Rational Software
• Smith, John (2001) The Estimation of Effort Based on Use Cases Rational Software, Australia
• Zavala, R.J. (2000) "La Ingeniería de Software" Ensayo

Herramientas

• Excel Software. Win A&D edición demo, estándar o educacional. Software. Herramienta CASE propietaria que utiliza varias notaciones, incluyendo UML.
• Microsoft. Visio versión profesional. Software. Herramienta propietaria para el modelado de negocios y software, incluyendo bases de datos y UML, pero "sin inteligencia", por lo que se recomienda utilizar con mucho cuidado o de plano mejor NO utilizarlo.
• Rational Software Suite. Tal vez el conjunto de herramientas CASE más completa que opera con una suite de herramientas automatizadas propietarias para soportar TODO el proceso de desarrollo de software y sus entregables.
• Tigris.org ArgoUML. Herramienta CASE de Modelado UML para java open source con licencia BSD.

Sitios de interés

• Association for Computing Machinery. http://portal.acm.org Biblioteca Digital. Se sugiere suscribirse.
• Carnegie Mellon - Software Engineering Institute http://www.sei.cmu.edu Reportes Técnicos y la más amplia información sobre desarrollo de software. Instituto apoyado por el DoD de lo EEUU
• Institute of Electrical and Electronics Engineers,  Inc  IEEE/IEE Electronic Library (IEL) Biblioteca Digital.
• Rational. Unified Modeling Language. Sitio de los creadores del UML con recursos, white papers, etc.
• Safari Biblioteca Digital. de O'Reilly Publisher. Acceso en-línea a miles de libros técnicos en computación y open source bajo suscripción mensual.
• The Rational Edge. http://www.therationaledge.com Revista Electrónica sobre desarrollo de software

• 70% Tareas Extraclase
• 30% Proyecto Final

• Se evaluará lo completo de las especificaciones del documento del proyecto y la consistencia entre los modelos, el prototipo y la documentación, por lo que es importante que sean consecuentes en su proceso. La evaluación será entre 0 (CERO) y 10 (DIEZ).
• La estrega de calificaciones será el viernes siguiente de entregado el proyecto, por lo que deberán acudir a la Fundación Arturo Rosenblueth para su consulta.
• El proyecto será evaluado punto por punto.

Tareas extraclase

Requisitos

• Los ensayos deberán contener el formato de un "paper científico" (ver el artículo "Software Engineering"): Título, Nombre del Autor, Datos de contacto del Autor e Institución, Fecha de Elaboración, Summary (de 120 palabras), Introducción al Tema (algo general destacando la importancia del tema para el autor y para su estudio), Marco Teórico (donde se expondrán los conceptos y conocimientos necesarios para que el lector interprete el documento), Desarrollo del Tema (donde se desarrollará la teoría, supuesto, tesis o hipótesis que sostiene el auto del paper, se discutirá, argumentará a favor en contra o propondrá su propia experiencia y visión del tema, pudiéndose intercalar comentarios del o los autores que haya revisado con comentarios y reflexiones propias),  Conclusiones y Recomendaciones (definirá las conclusiones y recomedaciones si hubiera, del tema) y Literatura Citada (deberán citarse todos los autores consultados identificando la o las páginas donde se tomó la cita o l referencia internet). Los nombre de los apartados (Marco Teórico y Desarrollo del Tema) pueden variar aunque el objetivo debe ser el mismo.
• Los ensayos serán entregados en limpio, escritos a mano, con citas bibliográficas, gráficas y demás elementos necesarios en el documento, bien organizado, "en limpio", "sin corrector". 
• La extensión del paper será de 7 a 10 cuartillas escrito a mano, con letra legible y sin faltas de ortografía, con márgenes de 2.5 cm (superior, inferior, derecho) y de 3 cm (izquierdo), en papel blanco bond. No se aceptarán hojas de cuaderno.
• Las figuras deberán recortarse y pegarse con la técnica "Cut & Paste" no digital: tijeras y resistol, debiendo tener todas su número de figura y un título de figura. 
• Cada hecho, dato, frase, afirmación y demás deberá estar documentado por una cita bibliográfica. N.B. Si no trae citas bibliográficas el trabajo ni se revisará, tomándose como calificación CERO.
• La Crítica será un mini-ensayo con la misma estructura pero de una extensión menor: de 3 a 4 cuartillas a mano, más centrado en la discusión. Tienen la finalidad de fomentar las habilidades de lectura y escritura.
• La entrega de las tareas tiene fecha límite bien establecida: siguiente clase al inicio de la misma como parte del pase de lista, en caso contrario, ya no serán recibidas y se darán por no entregadas con una calificación de CERO. 
• Se sugiere conservar una copia y compartirla con los demás compañeros de clase como apoyo a la propia clase publicándola en su sitio web. 
• La elaboración es individual y se calificarán los puntos del formato del paper, la calidad del contenido, la organización , la certeza y originalidad de las afirmaciones en la discusión del tema y las conclusiones. 
• Entregas (inicio de la clase como pase de lista)

Proyecto final

El proyecto final tiene la finalidad de sintetizar el conocimiento y expresar de una manera práctica lo aprendido, de tal manera que se genere un documento en papel y electrónico en un CD anexo al documento para su evaluación. Asegurarse de que el CD es leible. La entrega final tiene fecha límite será la siguiente clase después de terminado el curso. La fecha es NO PRORROGABLE y la entrega en es en las oficinas de la fundación en la Ciudad de México, donde deberán recabar acuse de recibido por medio del profesor o con la asisente del posgrado. El trabajo será escrito en formato RTF, HTML (hipertexto) o PDF con imágenes en jpg, gif o png y comprenderá lo siguiente:

• Portada
• Objetivos
• Justificación
• Delimitación del Problema
• Requerimientos (Documentar el proceso, la entrevista con los usuarios o "stakeholders" y el acuerdo de diseño)
• Actores documentados
• Marco Teórico y antecedentes de desarrollos para problemas similares similares
• Modelo de Casos de Uso
  • Diagrama de Casos de Uso
  • Casos de Uso (textual) y Diagramas de Secuencias (uno o varios por Caso de Uso)
  • Casos de Prueba (de todos los casos de uso)
• Modelo de Negocio
  • Diagrama de Clases
  • Clases documentadas en los diagramas con notas (atributos, dominio de cada uno, excepciones, valores iniciales, tipos de dato, etc., métodos, persistencia)
  • Diagramas de Estados (mostrar el ciclo de vida de los objetos)
  • Diagramas de Actividades (flujos de trabajo)
  • Interfases de Usuario (prototipos con controles html para entender los requerimientos)
• Modelo de Implementación
  • Arquitectura (arquitectura de la aplicación y el modelo de operación propuesto)
  • Diagramas de Componentes (la forma en que se agrupará el código)
  • Diagrama de Despliegue (distribución del código y procesos ejecutables ya operando)
  • Script de Pruebas y control de calidad (Proponer un script de pruebas para los casos de prueba y criterios de aceptación de las pruebas)
• Prototipo (para entender claramente los requerimientos)
  • Instrucciones para su instalación, configuración y ejecución
  • Archivo ejecutable
  • Interfases de Usuario
  • Archivos (modelos, código, datos de prueba, scripts, etc.)
  • Resultados de Pruebas
• Experiencias, Sugerencias y Recomendaciones
• Anexo 1: Todos los borradores y demás documentos obtenidos como formatos, archivos, etc, y aquellos generados en el proceso (incluyendo a mano).
• Anexo 2: Todas las versiones de los prototipos generadas en el proceso.

Reglas

• Regirá el reglamento vigente para alumnos
• Asistir puntualmente a clases
• Las tareas deben incluir la bibliografía y/o la referencia completa.
• Solo se aceptarán tareas en español.
• Solicitar ayuda al profesor vía correo electrónico, misma que será contestada a más tardar 24 horas después y excepcionalmente 72 horas después

• "Que haya sido el primer curso de la maestría en donde me he desvelado"... González, J. L.
• "Nada en lo absoluto"... González, O.
• "Que haya sido muy corto el tiempo"... Martínez, M. A.
• "Demasiadas diapositivas" Pineda, J. L.
• "Lo que me disgutó?... El examen"... Sánchez, A.
• "Se volvió un poco tedioso la manera de exponer las clases... las diapositivas..." Toledo, A.

Comentarios, recomendaciones y sugerencias al instructor

• "... debería enfocarse más a enseñar el UML, ya que ahí está la clave para aprovechar más este curso y aprender más rápido a modelar" Camero, M.
• "Me pareció a mi punto de vista la materia donde más he aprendido" Cañízares, J. C.
• "Me hubiera gustado más práctica en el UML, pero aprendí" Catarino, Z.
• "Me gustaría hacer más dinámico el curso" Fuentes, M. A.
• "... lo felicito por su brillante cátedra" Gallardo, C. M.
• "... distribuya más su material, porque nos saturó de información los primeros días" González, J. L.
• "Está muy bién estructurado el curso. Un poco excesivo en cantidad de material, pero excelente!" González, O.
• "... Un buen curso, nos hizo reflexionar sobr los problemas existentes actualmente" Hernández, N.
• "... En general, como persona y como maestro me pareció muy bueno" Martínez, M. A.
• "... Me disgustó la cantidad de información que se vió (metodologías) que al final no se ocupan...Felicitarlo por su gran entrega y responsabilidad para dar sus clases, al menos para mí fue un parteaguas en la MCC para cambiar de actitud hacia cómo ver y como pensar como desarrolladores de sistemas... eso fué lo que más me dejó del curso. Quzás no era el objetivo de este curso pero ese impacto tuvo" Martínez, R.
• "La manera en que explicó los temas y diagramas los entendí perfectamente, pero a la hora de su aplicación se me dificultó por no entender el problema"... Méndez, A. A.
• "Gracias por la motivación que me dió y enseñarme una parte de mi profesión que me hacía falta. Le agradezco profundamente" Monroy, L. F.
• "Muy buen método de motivación grupal. Traiga más ejemplos" Pineda, J. L.
• "Excelente forma de comunicar y transmitir los conceptos del curso... excelente manejo de relación con el grupo" Toledo, A.
• "Que el material sea distribuido previamente al curso" Trinidad, G.
• "Todo en particular estuvo ameno y me agradó el curso... sé cómo modelar un problema del mundo real"... Vargas, N.
• "Es la primera vez que veo y donde tuvimos algo de práctica activa y la forma de convivir en equipo y las responsabilidades que cada quien tuvo. En horabuena!" Villasana, J.
• "Excelente y con mucha disposición" Zárate, A.

Desde el 17 de enero del 2003, 23:06 hr CST, tu eres el visitante

Fecha de última actualización: 05 de enero del 2004, 12:45 hr CST

Email: jzavalar@yahoo.com

Regresar