INGENIERÍA
ITIANOS
3ro
ITIANOS
TSU
4to
Ingeniería
7mo
ADO-ES 6A y 6B
El alumno será capaz de aplicar métodos propios del análisis y diseño orientado a objetos para estructurar problemas de diversos dominios.
Dar al alumno la capacidad para descomponer los problemas con enfoque orientado a objetos. Esto le permitirá visualizar el mundo como una colección de objetos que interaccionan para conseguir un propósito de nivel superior y así poder construir sistemas de software complejos.
En la asignatura “Análisis y Diseño Orientado a Objetos” se abordan las principales técnicas de análisis y diseño requeridas para la implementación de Aplicaciones Orientadas a Objetos (AOO). Las herramientas cubiertas en esta asignatura permitirán al alumno acelerar el proceso de implementación, partiendo de un análisis apropiado, además de implementar AOO de forma adecuada. También se conocerán las herramientas software especializadas para la generación de los diferentes diagramas requeridos para documentar las fases de análisis y diseño.
Los sistemas software que actualmente se demandan y que los profesionales de las tecnologías de la información desarrollan requieren de la aplicación de un proceso que garantice la calidad del producto, en el cual las disciplinas críticas son el análisis y el diseño del software. En esta asignatura se hace especial énfasis en la aplicación del proceso unificado, el cual integra las mejores prácticas de análisis y diseño orientado a objetos, haciendo uso del lenguaje estándar de modelado UML. A través de situaciones reales, el alumno aprenderá a realizar una especificación formal de los requerimientos de software, así como describir un sistema software desde diversos enfoques a través de la creación de modelos descritos a través de diagramas UML.
Enrolarse al moodle.upgop.edu.mx
| HORA | LUNES | MARTES | MIÉRCOLES | JUEVES | VIERNES |
|---|---|---|---|---|---|
| 7:30-8:20 | |||||
| 8:20-9:10 | 6B | 6B | 6B | 6B | 6B |
| 9:10-10:00 | 6B NP | 6B NP | 6A | 6A | 6A |
| 10:00-10:50 | 6A | 6A | 6A NP | 6A NP | |
| 10:50-11:40 | |||||
| 11:40-12:30 | |||||
| 12:30-13:20 | |||||
| 13:20-14:10 |
Análisis y diseño orientado a objetos de sistemas usando UML BENNETT Simon, Steve McRobb, Ray Farmer 2007 Mc Graw Hill MA, USA 2006 8448156404
Utilización de UML en Ingeniería del Software con Objetos y Componentes PERDITA Stevens, Rob Pooley 2007 Addison-Wesley Barcelona, España 2007 9788478290864
Object-oriented analysis and design with applications BOOCH Grady, Robert A. Maksimchuk, Michael W. Engle 2007 Addison Wesley MA, USA 2006 978-0201895513
UML 2 Iniciación, ejemplos y ejercicios corregidos DEBRAUWER Laurent, Fien Van der Heyde 2009 ENI Barcelona, España 2008 9782746047419
UML 2 ARLOW Jim, Ila Neustadt 2008 Anaya Multimedia Madrid, España 2008 9788441520332
Análisis y diseño de sistemas KENDALL Kenneth E., Julie E. Kendall, Antonio Núñez Ramos 2007 Pearson Educación Madrid, España 2007 9789702605775
Introducción
Existen diferentes maneras de clasificar las metodologías de desarrollo de software o modelos de proceso de software. A continuación se presenta una liga que los clasifica en cuatro grupos: 1) Metodología de Análisis y Diseño de Sistemas Estructurados (SSADM, Structured Systems Analysis and Design Methodology), 2) Metodología de Diseño Orientado a Objetos (OOD, Object-Oriented Design), 3) Desarrollo Rápido de Aplicaciones (RAD, Rapid Application Developmnent) y 4) Metodologías Ágiles. Además explica qué es un proceso de desarrollo de software y sus principales actividades así como algunas herramientas que se pueden utilizar durante el desarrollo de software. El estándar internacional ISO/IEC 12270 describe el método para seleccionar, implementar y monitorear el ciclo de vida del software.Da clic en esta liga para ir al recurso
Actividad 1.1 (ED1 Parte 1)
En tu cuaderno, utilizando la referencia anterior responde las siguientes preguntas:
Introducción
A continuación se presenta una lista de otra forma de clasificar las metodologías o modelos de procesos de software. Analiza cada una de ellas.
Clasificación de los modelos de proceso de software
Actividad 2.1 (EP1)
Elabora un power point en donde agregues una ilustración de cada una de las metodologías descritas anteriormente. Súbela al moodle.
Proceso de desarrollo de software
Un proceso en forma general es un conjunto de actividades ordenadas en las que se define:
Evolución del RUP
El RUP es el resultado de más de 3 décadas de conocimiento unificado:
Definición
Es un proceso de negocios genérico para la ingeniería de software orientada a objetos. Describe una familia de procesos de ingeniería de software relacionados, que comparten una estructura y arquitectura común de procesos. El RUP provee un método disciplinado para asignar tareas y responsabilidades dentro de una organización de desarrollo. Su meta es asegurar la producción de software de alta calidad, que conozca las necesidades de los usuarios, dentro de un calendario y presupuesto predecible.
Características
UML en RUP
UML aporta el modelado y el transporte del conocimiento a los distintos equipos de trabajo y el RUP el proceso o la logística para el desarrollo, entre los modelos mas importantes que aporta el UML están: el modelo de casos de uso, el modelo de análisis, el modelo de diseño y el modelo de distribución.
UML
Unified Modeling Language (Lenguaje Unificado de Modelado) es un lenguaje de modelado, un lenguaje visual en el que se trabaja con cajas, flechas y diagramas. Afianza las claves y conceptos más usados en la programación orientada a objetos. Permite poder representar las ideas de cómo se debe estructurar los programas de una forma más visual. UML ayuda a:
Evolución de UML
Diagramas UML
Requerimientos funcionales y no funcionales
Un proceso centrado en la arquitectura
El RUP define la arquitectura como: la organización o la estructura de los componentes importantes de un sistema interactuando mediante interfaces. Entiendase por un componente el diagrama de clases, cliente, usuario, el modelo de casos de uso, etc. La arquitectura en el RUP se representa por medio de lo que se llama vistas arquitectónicas.
Modelo 4+1 vistas de Kruchten
El modelo “4+1” de Kruchten, es un modelo de vistas diseñado por el profesor Philippe Kruchten y que encaja con el estándar “IEEE 1471-2000” (Recommended Practice for Architecture Description of Software-Intensive Systems) que se utiliza para describir la arquitectura de un sistema software intensivo basado en el uso de múltiples puntos de vista.
Si un arquitecto nos muestra un plano de una casa (como la de la siguiente imagen), nos esta mostrando una vista de la casa y como no tenemos ni idea de arquitectura, cuando nos explique o nos de un documento en el que explique que un determinado símbolo del plano representa a una puerta u otro símbolo representa una mesa, nos estará dado un punto de vista para que podamos entender el plano de la casa. Si mas tarde nos mostrase otro plano (o maqueta) de la casa, nos estaría dando otra vista de la casa y nos tendrá que explicar el nuevo punto de vista, es decir, que nos tendrá que explicar que significa cada símbolo u objeto de esa nueva vista.
Pues sí, lo que propone Kruchten es que un sistema software se ha de documentar y mostrar (tal y como se propone en el estándar IEEE 1471-2000) con 4 vistas bien diferenciadas y estas 4 vistas se han de relacionar entre sí con una vista más, que es la denominada vista “+1”. Estas 4 vista las denominó Kruchten como: vista lógica, vista de procesos, vista de despliegue y vista física y la vista “+1” que tiene la función de relacionar las 4 vistas citadas, la denominó vista de escenario.
Cada una de estas vistas ha de mostrar toda la arquitectura del sistema software que se esté documentando, pero cada una de ellas ha de documentarse de forma diferente y ha de mostrar aspectos diferentes del sistema software. A continuación, pasamos a explicar que información ha de haber en la documentación de cada una de estas vistas.
Proceso iterativo e incremental
Consiste en la iteración de varios ciclos de vida en cascada. Al final de cada iteración se entrega una versión mejorada.
Fases del RUP
Diferencias entre UP y RUP
El Proceso Unificado es un nombre genérico para una familia de modelos de procesos que cumplen una serie de criterios, como ser iterativos e incrementales, impulsados por casos de uso y enfocados en abordar los riesgos de manera temprana. Define cuatro fases del proyecto: Inicio, Elaboración, Construcción y Transición.
El proceso unificado de racional es un refinamiento del proceso unificado que fue creado por Rational Software (ahora propiedad de IBM). Utiliza una serie de herramientas de software junto con un marco de proceso para definir cómo llevar a cabo las actividades necesarias para ejecutar un proyecto de software, pero aún así proporciona un marco para la adaptación para satisfacer las necesidades de una organización (o equipo).
Otras mejoras en el Proceso Unificado incluyen el Proceso Unificado Agile de Scott Ambler y el Proceso Unificado Abierto de la Fundación Eclipse .
Actividad 3.1 (EC1)
Resuelve un cuestionario acerca del RUP. Fecha por asignar en clase.
INTRODUCCIÓN: En el siguiente documento encontrarás información acerca de la visión general de UML, donde se describe en qué es esencial en la construcción de software, los diagramas qué utiliza, sus inconvenientes y algunos ejemplos de diagramas. Da clic aquí para acceder al documento.
ACTIVIDAD 2.1: Responde en tu cuaderno las siguientes preguntas y súbelas al moodle:
Un modelo del dominio es una representación visual de las clases conceptuales u objetos del mundo real en un dominio de interés. También se les denomina modelos conceptuales modelo de objetos del dominio y modelos de objetos de análisis. Este artefacto se crea en la disciplina del modelado del negocio. Para diseñar el modelo del dominio es necesario seguir los siguientes pasos:
ACTIVIDAD 2.2: Elabora el modelo del dominio del siguiente problema llamado "RESCATANDO A LA REINA"
Elabora un videjuego en donde el usuario tenga la posibilidad de seleccionar a cuatro de los siguientes personajes:
ACTIVIDAD 2.3 Investiga los tipos de modelados del comportamiento, estructural y arquitectónico.
Existen dos tipos de casos de uso:
ACTIVIDAD 2.4 Elabora los casos de uso breves siguiendo los requisitos de la ACTIVIDAD 2.2
ACTIVIDAD 2.5 Elabora los casos de uso informales siguiendo los requisitos de la ACTIVIDAD 2.2
ACTIVIDAD 2.6 Elabora los casos de uso completos siguiendo los requisitos de la ACTIVIDAD 2.2
ACTIVIDAD 2.7 Elabora los diagramas de caso de uso siguiendo los requisitos de la ACTIVIDAD 2.2
ACTIVIDAD 2.8 Elabora el diagrama completo de caso de uso siguiendo los requisitos de la ACTIVIDAD 2.2
INDICACIONES: En la siguiente presentación encontrarás información sobre los diagramas de estados y diagramas de actividad. Da clic aquí para acceder a la presentación.
ACTIVIDAD 2.9 Elabora el diagrama de estados de una laptop.
ACTIVIDAD 2.10 Elabora el diagrama de actividades del videojuego.
ACTIVIDAD 2.11 Elabora los diagramas de estados de los siguientes puntos:
ACTIVIDAD 2.12 Elabora los diagramas de actividades de los siguientes puntos:
INDICACIONES: En la siguiente liga encontrarás información de cómo elaborar los diagramas de secuencia. Da clic aquí para acceder a la presentación.
ACTIVIDAD 2.13 Elabora los siguientes diagramas de secuencia:
Listas Enlazadas Dobles Circulares o Doblemente Enlazadas Circulares
Clase Nodo
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace Estructura_U3_Practica3_ListasDbleEnlazadas
{
class Nodo
{
public object Dato { get; set; }
public Nodo Siguiente { get; set; }
public Nodo Anterior { get; set; }
public Nodo(object valorDato) : this (valorDato, null)
{
}
public Nodo(object valorDato, Nodo siguiente)
{
Dato = valorDato;
Siguiente = siguiente;
}
}
}
Clase Lista
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace Estructura_U3_Practica3_ListasDbleEnlazadas
{
class Lista
{
Nodo nodoPrincipio, nodoUltimo;
public Lista()
{
nodoPrincipio = nodoUltimo = null;
}
public bool Vacio()
{
return nodoPrincipio == null;
}
public void AgregarNodoAlPrincipio(object valorNodo)
{
if (Vacio())
{
nodoPrincipio = nodoUltimo = new Nodo(valorNodo);
}
else
{
nodoPrincipio = nodoPrincipio.Anterior = new Nodo(valorNodo, nodoPrincipio);
}
nodoPrincipio.Anterior = nodoUltimo;
nodoUltimo.Siguiente = nodoPrincipio;
}
public void AgregarNodoAlUltimo(object nodoValor)
{
if (Vacio())
{
nodoPrincipio = nodoUltimo = new Nodo(nodoValor);
}
else
{
Nodo nodoNuevo = new Nodo(nodoValor);
nodoNuevo.Anterior = nodoUltimo;
nodoUltimo = nodoUltimo.Siguiente = nodoNuevo;
}
nodoPrincipio.Anterior = nodoUltimo;
nodoUltimo.Siguiente = nodoPrincipio;
}
public void EliminarNodoAlPrincipio()
{
if (Vacio())
{
throw new ExcepcionListaVacia();
}
else
{
object nodoEliminar = nodoPrincipio.Dato;
if (nodoPrincipio == nodoUltimo)
{
nodoPrincipio = nodoUltimo = null;
}
else
{
Nodo nodoTemp = nodoPrincipio.Siguiente;
nodoTemp.Anterior = nodoPrincipio.Siguiente = null;
nodoPrincipio = nodoTemp;
nodoPrincipio.Anterior = nodoUltimo;
nodoUltimo.Siguiente = nodoPrincipio;
}
}
}
public void EliminarNodoAlUltimo()
{
if (Vacio())
{
throw new ExcepcionListaVacia();
}
object nodoAEliminar = nodoUltimo.Dato;
if (nodoPrincipio == nodoUltimo)
{
nodoUltimo = nodoPrincipio = null;
}
else
{
Nodo nodoTemp = nodoUltimo.Anterior;
nodoTemp.Siguiente = null;
nodoUltimo.Anterior = null;
nodoUltimo = nodoTemp;
nodoPrincipio.Anterior = nodoUltimo;
nodoUltimo.Siguiente = nodoPrincipio;
}
}
public void MostrarListaPU()
{
if (Vacio())
{
Console.WriteLine("Está Vacía");
return;
}
Console.WriteLine("\nLa lista contiene:");
Nodo nodoTemp = nodoPrincipio;
while (nodoTemp != nodoUltimo)
{
Console.Write("|{0}|°|==", nodoTemp.Dato);
nodoTemp = nodoTemp.Siguiente;
}
while (nodoTemp != nodoPrincipio)
{
Console.Write("|{0}|°|==", nodoTemp.Dato);
nodoTemp = nodoTemp.Anterior;
}
Console.Write("|{0}|°|", nodoTemp.Dato);
}
public void MostrarListaUP()
{
if (Vacio())
{
Console.WriteLine("Está Vacía");
return;
}
Console.WriteLine("\nLa lista contiene:");
Nodo nodoTemp = nodoUltimo;
while (nodoTemp != nodoPrincipio)
{
Console.Write("|{0}|°|==", nodoTemp.Dato);
nodoTemp = nodoTemp.Anterior;
}
while (nodoTemp != nodoUltimo)
{
Console.Write("|{0}|°|==", nodoTemp.Dato);
nodoTemp = nodoTemp.Siguiente;
}
Console.Write("|{0}|°|", nodoTemp.Dato);
}
}
}
Excepción Lista Vacía
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace Estructura_U3_Practica3_ListasDbleEnlazadas
{
class ExcepcionListaVacia : ApplicationException
{
public ExcepcionListaVacia() : base("Esta vacía") { }
}
}
Probar Lista Vacía
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace Estructura_U3_Practica3_ListasDbleEnlazadas
{
class ProbarLista
{
static Lista lista;
static void Main(string[] args)
{
lista = new Lista();
Menu();
Console.WriteLine("Fin"); Console.ReadLine();
}
static void Menu()
{
string opcion = "";
object nodo;
do
{
Console.WriteLine("\n¿Qué desean hacer?");
Console.WriteLine("1. Agregar Nodo al Principio");
Console.WriteLine("2. Agregar Nodo al Último");
Console.WriteLine("3. Eliminar Nodo al Principio");
Console.WriteLine("4. Eliminar Nodo al Último");
Console.WriteLine("5. Mostrar Lista del Principio al Último");
Console.WriteLine("6. Mostrar Lista del Último al Principio");
Console.WriteLine("EXIT. Salir");
opcion = Console.ReadLine();
switch (opcion)
{
case "1":
Console.WriteLine("Ingresa un dato para el Nodo:");
nodo = Console.ReadLine();
lista.AgregarNodoAlPrincipio(nodo);
break;
case "2":
Console.WriteLine("Ingresa un dato para el Nodo:");
nodo = Console.ReadLine();
lista.AgregarNodoAlUltimo(nodo);
break;
case "3":
Console.WriteLine("Eliminando Nodo al Pincipio");
lista.EliminarNodoAlPrincipio();
break;
case "4":
Console.WriteLine("Eliminar Nodo al Último");
lista.EliminarNodoAlUltimo();
break;
case "5":
Console.WriteLine("Mostrar Lista del Principio al Último");
lista.MostrarListaPU();
break;
case "6":
Console.WriteLine("Mostrar Lista del Último al Principio");
lista.MostrarListaUP();
break;
default:
break;
}
} while (opcion != "exit" && opcion != "EXIT");
}
}
}
INDICACIONES: En la siguiente liga encontrarás información sobre cómo elaborar los diagramas de colaboración. Da clic aquí para descargar el documento
ACTIVIDAD 2.14 Elabora los siguientes diagramas de colaboración:
Explicación de los conceptos básicos de POO
Da clic aquí para ver los conceptos básicos de la POO aplicados a C#
Tipos de asociaciones
Da clic aquí para ver el tipo de asociaciones en los diagramas de clases
Agregación, composición y asociación en C#
Da clic aquí para acceder al link
Explicación de los diagramas de clases
Da clic aquí para ver la presentación
ACTIVIDAD 2.15: Utiliza como referencia los enlaces del tema 8 y responde las siguientes preguntas:
ACTIVIDAD 2.16: Elabora los siguientes diagramas de clases, utilizando la simbología adecuada:
ACTIVIDAD 2.17: Realiza los siguientes diagramas de clases:
ACTIVIDAD 2.18: En los siguientes enlaces encontrarás información sobre los diagramas de componentes y de despliegue. Da clic aquí para obtener información sobre los diagramas de componentes. Da clic aquí para obtener información sobre los diagramas de despliegue Responde y anota en tu cuaderno las siguientes preguntas:
ACTIVIDAD 2.19: Elabora el diagrama de paquetes de tu proyecto de ingeniería de software. Utiliza como referencia este enlace para obtener mas información sobre los diagramas de paquetes.
ACTIVIDAD 2.20: Los diagramas de objetos se representan igual que los diagramas de clases, solo que en lugar de especificar la lateral de cada variable, se colocan los valores de cada propiedad y el nombre de la instancia de cada clase. Da clic aquí para mas información sobre los diagramas de objetos. Utilizando los diagramas de clases de la actividad 2.16 elabora de cada uno de ellos el diagrama de objetos, indicando los nombres de las instancias de las clases y los valores de los atributos.
Evaluación lunes 5 y martes 6 de agosto (TODOS LOS DIAGRAMAS DE LA SEGUNDA UNIDAD)
Da clic aquí para ver los requisitos 1
Da clic aquí para ver los requisitos 2
Diagramas UML a elaborar:
Fecha de entrega: domingo 11 de agosto de 2019.
INDICACIONES: Elabora los artefactos UML y los requisitos para el proyecto de la aplicación de idiomas. En el caso de los requisitos presentar un documento word o pdf y en los diagramas hacerlos en Visio. Para realizar la evidencia sigue los siguientes puntos para crear los respectivos artefactos y separarlos por carpetas según lo descrito cada punto:
REQUISITOS DE LA APLICACIÓN PARA APRENDER IDIOMAS
Se solicita el desarrollo de una aplicación para aprender idiomas. A continuación se describe cada uno de los requisitos:
Fecha de entrega: Miércoles 14 de agosto de 2019.
INDICACIONES: Elabora los artefactos UML y de requisitos para el proyecto de la materia de ingeniería de software (6A) y análisis y diseño de sistemas (6B). En el caso de los requisitos presentar un documento word o pdf y en los diagramas hacerlos en Visio. Para realizar la evidencia sigue los siguientes puntos para crear los respectivos artefactos y separarlos por carpetas según lo descrito cada punto: