Programación de Aplicaciones

Nombre de la asignatura:

Programación de Aplicaciones

Competencias:

• Dirigir proyectos de tecnologías de información (T.I.) para contribuir a la productividad y logro de los objetivos estratégicos de las organizaciones utilizando las metodologías apropiadas.
• Evaluar sistemas de tecnologías de información (T.I.) para establecer acciones de mejora e innovación en las organizaciones mediante el uso de metodologías para auditoría.

Cuatrimestre:

Séptimo

Horas teóricas:

31

Horas prácticas:

44

Horas totales:

75

Horas totales por semana cuatrimestre:

5

Objetivo de aprendizaje:

El alumno empleará el paradigma de la programación Orientada a Objetos para el desarrollo de sistemas de información y su seguridad a nivel avanzado.

Evaluaciones por Unidad

Erich Gamma (2008) Patrones de Diseño Madrid España Addison Wesley

Garrido, José M. (2003) Object-Oriented Programming (From Problem Solving to JAVA) (Programming Series) San California USA Charles River Media Jose

James W. Cooper (2002) Introduction to Design Patterns in C#. San Jose California USA Addison-Wesley Professional

Steven John Metsker (2004) Design Patterns in C# San Jose California USA Addison-Wesley Professional

Tema 1 - Paradigma de POO

A continuación se presentan algunas definiciones importantes de POO:

Paradigma:
Ejemplo o modelo de algo.

Paradigma de programación orientado a objetos (POO):
Modelo definido a través de comunidades de objetos.

Instrucciones de control:
Variaciones o alteraciones a la secuencia normal de ejecución de un programa.

Objeto:
Instancia de una clase.

Instancia:
Objeto que derive de otro. Excepto la clase Object.

Clase:
Plano para personalizar un tipo de dato. Sus miembros pueden ser: atributos, propiedades, métodos y eventos.

Atributos:
Variables internas y constantes.

Propiedades:
Características del objeto con get y set.

Métodos:
Acciones que realiza el objeto.

Eventos:
Notificaciones que se producen cuando se realiza una acción.

Constructor:
Método que inicializa un objeto.

Destructor:
Método invocado antes de la instancia para eliminarse de la memoria.

UML:
Unified Modeling Language. Lenguaje para modelar objetos.

Eventos:
Notificaciones que se producen cuando se realiza una acción.

Herencia:
Crear objetos a partir de otros. Objetos que heredan miembros de otro objeto.

Polimorfismo:
Muchas formas. Métodos que adaptan la forma conveniente.

Encapsulamiento:
Separar elementos de abstracción por comportamientos.

Modificadores de acceso:
Nivel de accesibilidad que tendrá un tipo o miembro desde otro. Public, Private, Internal, Protected.

Tema 2 - Agregación y asociación

En los diagramas de clases de UML, se utiliza la siguiente simbología:

Herencia:
Una clase hereda a otra. Para usar herencia es necesario que la clase base sea abstracta y contenga métodos abstractos.

Agregación:
Una clase se asocia con otra. Una clase fuerte se asocia con una débil. Un objeto prestamo se asocia con objetos pagos.

Asociación:
Una clase se asocia con otra. Un objeto alumno se relaciona con objetos materias.

Implementación:
Una clase implementa de una interfaz. Los miembros declarados en la interfaz son implementados en una clase.

Composición:
Una clase se compone de otras clases. Un objeto carro se compone de objetos llantas, puertas, etc.

Generalización:
Es el definir una super clase, para que comparta los miembros en común a las subclases.

Extención:
Es un tipo de implementación pero indica herencia. Las subclases heredan o extienden de una superclase.

Tema 3 - WinForms y WPF

WPF por sus siglas Windows Presentation Foundation, es la reciente tecnología de Microsoft para crear GUI utilizando .NET Framework. GUI significa Interfaz Gráfica de Usuario. Windows Maneja una GUI junto con los navegadores. Un marco de GUI tiene la ventaja de que maneja una variedad de controles como tags, inputs, etc. Trabajar sin GUI es mucho más complejo. Existen muchos marcos de GUI, pero los más mencionados por los desarrolladores de Microsoft son WinForms y WPF.

¿Qué es XAML?
Por sus siglas, eXtensible Application Markup Language, es una alternativa de Microsoft a XML para diseñar una GUI. XAML es una forma sencilla de escribir interfaces de usuario, tan simple como usar HTML.

Saber Hacer 7A

PRÁCTICA 1 - Graficar funciones utilizando Buttons en WinForms
INDICACIONES: Elabora una aplicación en WinForm C# en donde grafiques, utilizando botones creados en tiempo de ejecución las siguientes funciones:

PRÁCTICA 2 - Creando un camión en tiempo de ejecución con WPF
INDICACIONES: Elabora una aplicación en WPF en donde utilizando controles (Buttons), estructures sus asientos, baños, asiento del chofer y puerta. Todo esto deberá ser creado en tiempo de ejecución. Al darle clic a un asiento de pasajeros, este deberá cambiar de color para indicar que el asiento fue ocupado.



PRÁCTICA 3 - Aplicación de Patos (Uso de clase y métodos abstractos)
INDICACIONES: Elabora una aplicación WPF para simular dos tipos de patos: Mallard Duck y Red Head Duck. La forma de windows es el escenario para los patos (un lago), los patos deberán ser creados como buttons o pictures. Al momento de crear los patos es necesario preguntar sus datos personales (nombre, edad, NSS). Después de crear al pato, es necesario implementar los siguientes eventos: 1) al hacer clic el pato deberá mostrar emitir un sonido, al hacer doble clic el pato deberá cambiar de posición (utilizar Thickness) y al hacer clic derecho, se deberá mostrar la información del pato. Favor de seguir la siguiente estructura del diagrama de clases.

Saber Hacer 7B

PRÁCTICA 1 - Graficar funciones utilizando Buttons en WinForms
INDICACIONES: Elabora una aplicación en WinForm C# en donde grafiques, utilizando botones creados en tiempo de ejecución las siguientes funciones:

PRÁCTICA 2 - Aplicación de Patos (Uso de clase y métodos abstractos)
INDICACIONES: Elabora una aplicación WPF para simular dos tipos de patos: Mallard Duck y Red Head Duck. La forma de windows es el escenario para los patos (un lago), los patos deberán ser creados como buttons o pictures. Al momento de crear los patos es necesario preguntar sus datos personales (nombre, edad, NSS). Después de crear al pato, es necesario implementar los siguientes eventos: 1) al hacer clic el pato deberá mostrar emitir un sonido, al hacer doble clic el pato deberá cambiar de posición (utilizar Thickness) y al hacer clic derecho, se deberá mostrar la información del pato. Favor de seguir la siguiente estructura del diagrama de clases.



PRÁCTICA 3 - Creando una avión en tiempo de ejecución
INDICACIONES: Elabora una aplicación WPF en donde se creen los controles en tiempo de ejecución. Los asientos del avión son buttons, deberás crear un button verde que represente el pasillo y agregar la numeración vertical (1,2,3...) y horizontal (A, B, C..). Al darle clic a los buttons, deberás pedirle al usuario que proporcione los datos del pasajero (nombre, apellido paterno, apellido materno, correo). Una vez registrados los datos del pasajero, el button deberá de cambiar de color a gris y ya no se podrá asignar a otro pasajero. El content del button deberá ser el precio en dólares.

Remedial

INDICACIONES: Elabora una aplicación en WPF C#, en donde construyas todos los elementos (asientos, pasillos, baños, entradas, escaleras) en tiempo de ejecución. El usuario al darle clic en un asiento, puede registrar su información (nombre, apellido paterno, apellido materno, edad y correo). Cuando el usuario haya registrado su información, el asiento deberá cambiar de color y mostrar la información registrada al darle doble clic. Al darle un clic derecho al asiento, muestra la opción para borrar el usuario registrado.

Tema 1 - Polimorfismo

Da clic aquí para ver el ejemplo de polimorfismo

Tema 2 - Clases abstractas

Da clic aquí para conocer más sobre clases abstractas

Da clic aquí para ver ejemplo de clases abstractas

Tema 3 - Interfaces

Da clic aquí para ver el ejemplo de interfaces

Da clic para obtener más información sobre interfaces

Saber Hacer 7A

Práctica3: Elabora la estructura del patrón estategia utilizando como referencia el siguiente diagrama. Pasos a seguir:

• Agrega las clases
• Identifica las clases abstractas y las interfaces
• Agrega la relación entre las clases: extends, implements, HAS-A
• Agrega el método SetWeapon() dentro de la clase correcta

Saber Hacer 7B

INDICACIONES: Da clic aquí para descargar la hoja de evaluación.

Patrón de diseño ESTRATEGIA (Strategy)

Saber 7B

Association, Aggregation, Composition, Abstraction, Generalization, Realization, Dependency
Da clic aquí para acceder a la información

Types Of Relationships In Object Oriented Programming (OOPS)
Da clic aquí para acceder a la información

Tema 1 - Conceptos básicos de un patrón de diseño

La siguiente información es tomada de la página de microsoft.com (fuente)

Libro de patrones de diseño "Head First Design Patterns"
Da clic aquí para acceder al libro de patrones de diseño

Definición de patrón de diseño
“Los patrones de diseño son el esqueleto de las soluciones a problemas comunes en el desarrollo de software.” Los Patrones de diseño son herramientas para solucionar problemas de Diseño enfocados al desarrollo de software, estos patrones deben ser reusables permitiendo así que sean adaptados a diferentes problemáticas.

Clasificación de los patrones de diseño

• Patrones Creacionales: Inicialización y configuración de objetos.
• Patrones Estructurales: Separan la interfaz de la implementación. Se ocupan de cómo las clases y objetos se agrupan, para formar estructuras más grandes.
• Patrones de Comportamiento: Más que describir objetos o clases, describen la comunicación entre ellos.

¿Por qué usar patrones de diseño?
Si queremos desarrollar aplicaciones robustas y fáciles de mantener, debemos cumplir ciertas "reglas". Lo pongo entre comillas porque aunque estas reglas de diseño son recomendables (muy recomendables), no son obligatorias. Siempre podemos decidir no aplicarlas. Aunque si no lo hacemos, hay que ser conscientes de la razón de no aplicarlas y de sus consecuencias.
Los patrones de diseño nos ayudan a cumplir muchos de estos principios o reglas de diseño. Programación SOLID, control de cohesión y acoplamiento o reutilización de código son algunos de los beneficios que podemos conseguir al utilizar patrones.

Tema 2 - SOLID

¿Qué es SOLID?
Solid es un acrónimo inventado por Robert C.Martin para establecer los cinco principios básicos de la programación orientada a objetos y diseño. Este acrónimo tiene bastante relación con los patrones de diseño, en especial, con la alta cohesión y el bajo acoplamiento. El objetivo de tener un buen diseño de programación es abarcar la fase de mantenimiento de una manera más legible y sencilla así como conseguir crear nuevas funcionalidades sin tener que modificar en gran medida código antiguo. Los costes de mantenimiento pueden abarcar el 80% de un proyecto de software por lo que hay que valorar un buen diseño. (fuente)

Para que estos cambios constantes cuesten lo menos posibles, Robert C. Martín nos propuso en el año 2000 unos principios para que nuestro código orientado a objeto sea más flexible. Estos principios están recogidos sobre el acrónimo SOLID. Seguramente habrás escuchado muchas veces la expresión ‘aplicaciones sólidas”, pues bien, lo de sólidas se refiere a que en el desarrollo se aplican estos principios. SOLID describe cinco principios fundamentales, uno por cada letra, sobre el diseño orientado a objetos. Veamos que significan: (fuente)

• S (SRP) – Principio de responsabilidad única (Single responsibility principle)
• O (OCP) – Principio de abierto/cerrado (Open/closed principle)
• L (LSP) – Principio de sustitución de Liskov (Liskov substitution principle)
• I (ISP) – Principio de segregación de la interfaz (Interface segregation principle)
• D (DIP) – Principio de inversión de la dependencia (Dependency inversion principle)

Echemos un vistazo a cada principio individualmente para entender porque SOLID puede ayudar a los desarrolladores a construir software de calidad. (Fuente)

S (SRP) - Principio de responsabilidad única (Single responsibility principle)
“Nunca debería haber mas de una razón en una clase para cambiar”

Como puedes observar, este principio dice que un objeto/clase debería únicamente tener una responsabilidad completamente encapsulada por la clase. Aquí, cuando hablamos de responsabilidad, nos referimos a una razón para cambiar. Este principio nos dirige hacia una cohesión más fuerte en la clase y un encaje más flojo entre la dependencia de clases, una mayor facilidad de lectura y un código con una complejidad menor.

Es mucho más difícil entender y editar una clase cuando tiene más de una responsabilidad. Por lo que si tenemos más de una razón para cambiar, la funcionalidad se divide entre dos clases y cada una se encargará de su responsabilidad.

Pensamos en separar las funcionalidades ya que cada una de ellas es un acceso al cambio. Cuando una clase tiene más de una responsabilidad, se acoplan y ello hace que el codigo base sea frágil. Lo que dificulta refactorizar cuando se requiere.

Ejemplo práctico con C#

O (OCP) – Principio de abierto/cerrado (Open/closed principle)
“Entidades de Software (classes, módulos, funciones, etc.) han de estar abiertas para extensiones, pero cerradas para modificaciones”

Aquí la idea es que una entidad permite que comportamiento se extienda pero nunca modificando el código de fuente. Cualquier clase (o cualquier cosa que escribas) debe de estar escrito de un manera que puede utilizarse por lo que es. Puede ser extensible, si se necesita, pero nunca modificado. Puedes tener esto en cuenta cuando escribas tus clases. Utiliza las clases de la manera que necesites, pero para modificar su comportamiento aparece cuando añades un código nuevo, nunca cuando lo modificas el viejo. El mismo principio puede aplicarse para módulos, paquetes y librerías.

Aplicando el principio de abierto-cerrado conseguiras un acople más relajado, mejoraras la lectura y finalmente, reducirás el riesgo de romper alguna funcionalidad ya existente.

Ejemplo práctico con C#

L (LSP) – Principio de sustitución de Liskov (Liskov substitution principle)
“Subtypes deben ser sustituidos por su tipo de base”

Como su nombre indica, este principio fue definido por Barbara Liskov. La idea aquí es que los objetos deberían ser reemplazados por ejemplos de su subtipo, y ello sin que la funcionalidad del sistema desde el punto de vista de los clientes se vea afectada. Básicamente, en vez de utilizar la implementación actual, deberías ser capaz de utilizar una clase base y obtener el resultado esperado. A menudo, cuando queremos representar un objeto, modulamos nuestra clase de bases en sus propiedades y en vez de eso, deberíamos poner más énfasis en su comportamiento.

Este principio básicamente confirma que nuestras abstracciones están conectadas y nos ayudan a conseguir un código que es fácil de reutilizar y una jerarquía de clases fáciles de entender.

Lo que muchos dicen es que este principio de Liskov tiene una fuerte relación que los anteriores, (open-close). Robert c Martin incluso dice que “una violación de LSP es una violación latente de OCP”.

Ejemplo práctico con C#

I (ISP) – Principio de segregación de la interfaz (Interface segregation principle)
“Classes implementan interfaces, no deberían ser forzadas a implementar los métodos no utilizados”

Aquí, se basa en cómo escribir interfaces. Entonces, qué significa? Básicamente, una vez la interfaz se convierte en larga, se necesita absolutamente de separarla en pequeñas partes más específicas. Una interfaz será definida por el cliente que lo utilice, lo que significa que el sera el unico que tenga conocimientos de los métodos relacionados con ellos.

En realidad, si añades métodos que no deberían estar ahí, las clases implementando la interfaz deberá implementar los métodos también. Esa es la razón, los clientes no deberían ser forzados a depender de las interfaces que no darán uso. Con ISP se intenta mantener un sistema desacoplado y así más fácil de refactorizar, cambiar y desplegar.

Ejemplo práctico con C#

D (DIP) – Principio de inversión de la dependencia (Dependency inversion principle)
“Módulos de altos modelos no deberían depender de niveles de modulos bajos, sino de abstracciones. Abstracciones no deberían depender de detalles; sino los detalles de la abstracción”

Este principio está principalmente basado en reducir las dependencias entre los módulos del código. Básicamente, este principio será de gran ayuda para entender cómo atar correctamente sistemas juntos. Si los detalles de tu implementación dependen de los altos niveles de abstracciones, te ayudará a conseguir un sistema bien acoplado. También, influirá en la encapsulación y cohesión de ese sistema.

Ejemplo práctico con C#

Tema 3 - Patrón estrategia

Design Principle

Identify the aspects of your application that vary and separate them from what stays the same.
Identifica los aspectos de tu aplicación que varian y separalos de los que hacen lo mismo.

Design Principle

Program to an interface, not an implementation.
Programa una interfaz, no una implementación.

Design Principle

Favor composition over inheritance.
Favorecer la composición sobre la herencia.

INDICACIONES: Elabora una aplicación en WPF en donde implementes el patrón estrategía utilizando el siguiente ejemplo:

Tema 4 - Patrón observador

Design Principle

Strive for loosely coupled designs between objects that interact.
Esfuércese por obtener diseños acoplados entre objetos que interactúan.

Loosely coupled design allow us to build flexible OO systems that can handle change becouse they minimize the interdependency between objects.
El diseño de bajo acoplamiento nos permite construir sistemas OO flexibles que pueden manejar el cambio porque minimizan la interdependencia entre los objetos.

Evaluación

INDICACIONES: Descarga el siguiente documento pdf, elabora el diagrama entidad relación en SQL Server y crea utilizando ADO.NET y Entity Framework para crear los controladores y las vistas.

Da clic aquí para descargar el documento