Iniciar proyecto con Power Builder y Subversion

Pautas Generales:

1. Obligatorio leer: "Buenas Prácticas de Gestión de Versiones con Subversion", de allí lo más importante:

• Trunk: Rama de desarrollo principal, nuestro desarrollo será en esta carpeta.
• Tags: Rama de gestión de versiones. Reservado para versiones cerradas, por tanto no se desarrollará sobre esta rama. Cada versión corresponde con los entregables del sistema.
• Branches: Rama con evoluciones paralelas al Trunk. No utilizar salvo para desarrollos auxiliares, levantamiento de errores que luego llevaremos al trunk y tag para pasar a producción.

2. Trabajaremos usando un servidor Subversion para el control de versiones y PBSCC para descomponer los objetos de los PBL de Power Builder, como expliqué en este post.

3. Antes de comenzar el desarrollo necesitaremos instalar: en el servidor el VisualSVN, y en cada cliente el TortoiseSVN y PBSCC pra el control de fuentes con Power Builder.
4. La dirección del Repositorio será de la siguiente forma: https://servidor.int/svn/Aplicacion/
5. El desarrollo lo haremos en la carpeta trunk del repositorio: https://servidor.int/svn/Aplicacion/trunk/


I. Instalación Inicial de las fuentes en el Servidor

1.1 Poner la versión inicial de las fuentes en el trunk
1.2 Hacer el primer tag llamado 1.0.0

II. Instalación inicial de cada desarrollador
2.1 Crear las carpetas "SVN-WORK" y "FUENTES"
2.2 En SVN-WORK se hará el primer update para descargar la versión a su copia de trabajo.
2.3 En la carpeta fuentes se deben grabar las fuentes (objetos PB: pbl, pbw, pbc...)

III. Instrucciones para el trabajo diario

Antes de editar un objeto de un PBL se debe coger con "CheckOut" y luego se podrá editar. Con esto también se bloquea el acceso de otros desarrolladores al objeto.

Al terminar la edición, se hace "CheckIn" que sube los cambios al repositorio

También se puede descartar los cambios trayendo la última versión del objeto con "Get Latest Version..."

Disciplina de Gestión de Proyectos

Es una Disciplina de Soporte de RUP.

Usamos la herramienta del RUP. Está entre las disciplinas

Tarea: ¿Cómo justificaríamos invertir en el proyecto?

La Gestión del Proyecto se hace desde que me aprueban el Proyecto. En realidad es el Acta de Constitución del Proyecto (Project Charter) la que da inicio a RUP.

Al inicio el Gestor de Proyecto debe hacer estos tres documentos:

• Casos de negocio
• Lista de Riesgos 
• Plan de Desarrollo de Software

El Project Charter lo firman:
El sponsor
El jefe de Sistemas
El jefe de la oficina que hizo el requerimiento
El jefe de alguna oficina con la que se integra el sistema.

Práctica la próxima clase, va a venir un enunciado para identificar objetos y clases. También conceptos básicos de UML.

Introducción al UML

1. Fundamentos del UML

Es un lenguaje Unificado de Modelado.
Tiene la característica de estar orientado a objetos.
Tiene gramática, sintaxis, elementos, reglas para nombrar estos elementos.

Estándar para el modelado de sistemas.
Es una notación, no es un proceso, ni es una metodología (como es RUP)

Creado en 1997. Se basa en metodologías antiguas: OMT, Booch, OOSE

Hubo cambios fuertes desde la versión 2.0 (en 2004)
Se espera que la versión 2.5 tenga grandes cambios también (aún no sale)

2. Estructura de UML

Elementos de UML

7 Elementos que intervienen en todos los diagramas: Clases, Interfaz, Colaboración, Casos de Uso, Clase Ativa, Componente y Nodo.
Curiosidad: Los actores son clases con un estereotipo
Los componentes son las librerías... los archivos físicos
Los componentes van en los nodos, son los equipos, servidores, discos duros... inclusive pueden ser hubs, routers... si es necesario

2 Elementos de Comportamiento:
Son la interacciones (flechas) y la Máquina de Estados (rectángulo redondeado)

Elemento de Agrupación: El Paquete
Elemento de Anotación: La Nota

Relaciones UML

Relación de Dependencia
Un elemento depende de otro



Relación de Asociación
Dos elementos necesitan trabajar en conjunto


Relación de Generalización
Apunta hacia el elemento general


Relación de realización
Un elemento de colaboración ayuda al caso de uso. Apunta hacia el caso de uso.




Diagramas UML

UML1.x
9 diagramas:
Diagrama de clases: de análisis, de diseño, de negocio. Varían por el estereotipo. Los únicos elementos son clases y relaciones (solo línea contínua)

Diagrama de casos de Uso: dos diagramas
Casos de Uso de Negocio: Expresa los procesos de la empresa, todos aquellos procesos que tienen relación con el sistema. El Actor (StickMan) y los casos de uso llevan un estereotipo de línea diagonal. La relación es una asociación simple sin flecha.
Casos de Uso del Sistema: Expresa las funciones de un sistema

Diagrama de Objetos: Modela las instancias de los elementos. Grafican un ejemplo, una instantánea.

Diagramas de Secuencia: Compuesto de Objetos, instanciados de una clase que ya exista. Es un modelo de análisis. Es una secuencia de mensajes y corresponde exactamente lo que debe ocurrir en un caso de uso. Es importante el orden en el que se envían los mensajes.

Diagrama de Colaboración: Corresponde al diagrama de secuencia, pero de distinta forma.

Diagrama de Estados: Muestra un valor de un atributo. Normalmente va pegado a una clase. Las líneas llevan los eventos y los mensajes. Tienen un solo inicio y pueden tener varios finales.

Diagrama de Actividades: Parecidos a los diagramas de flujo. Un solo inicio, las actividades son atómicas (no pueden ser subdividido). Corresponden a una operación o un caso de uso.

Diagrama de Componentes: Para los archivos físicos.

Diagrama de Despliegue: Va junto al de componentes. Muestra qué componentes van en qué nodo (servidor, pc de usuario y otros elementos de la red también).

UML2.x
Han cambiado algunas cosas:
d. de actividad tiene nuevos elementos
d. de Estados ahora se llama Máquina de Estado
d. Secuencia tmabién tiene nuevos elementos.

Diagrama de Visión de Interacción: Nuevo diagrama que muestra la secuencia entre diagramas, parecido al diagrama de actividad. Realmente puede expresar la secuencia de varias cosas, no solo casos de uso, como una caja negra.

Diagrama de tiempos: Para programar tiempos en dispositivos o piezas de software.

d. Comunicación es el de colaboración

Diagrama de Paquetes, aunque ya se usaba intuitivamente.

Diagrama de Estructura Compuesta: para software que pueden crear su propia estructura de clase o nuevos tipos de datos.

Hay una Estructura Taxonómica que categoriza los diagramas entre d. de Estructura (estáticos) y de Comportamiento (dinámicos)

También en la versión 2.0 aparecen los frames que tienen etiquetas: pkg, cmp (componentes), uc, act, stm (Máquina de Estado) y sd (d. de interacción)

Mecanismos Comunes
Elementos de Apoyo que ayudan a entender mejor el diagrama.

Especificación. un documento que ayuda a poner por escrito precondiciones, post condiciones, restricciones, errores,  etc


3. Arquitectura UML

4+1



REGLAS EN UML

Hay consideraciones, las cosas no pueden combinarse de cualquier manera, existen reglas.

Hay reglas para nombres, alcance, visibilidad y 2 mas

Para nombres:

La dependencia entre casos de uso include y extend.

Nombes de caso de uso de sistema se escriben en infinitivo, los nombres de casos de uso de negocio no tienen reglas porque dependen de cada negocio.

Para alcance: Da el significado específico a un nombre. Me dice cuando mostrar o no mostrar cosas. Como el include que en los casos de uso nunca van de uno con uno.

Para visibilidad:  los signos (+ u otros ). O la regla que dice que siempre debe haber estereotipo gráfica o textualmente.

Para integridad: relaciones apropiadas entre elementos.

Ejm: Un actor q no puede tener include con un caso de uso. include entre dos casos de uso.

Para Ejecución

Luego usamos el Enterprise Arquitect

- Herramienta poderosa... licenciada... pero no es fiel a UML para analisis de negocio

- Copy and Paste poderosos... al pegar en Word le pone automáticamente el frame

- Crear los elementos en sus paquetes y luego traerlos al diagrama como vínculo.

- Asegurarse de abrir el diagrama correcto con doble click... pasa seguido que ponemos actores en un sitio y no era...

- En Business Entities, para crear los objetos de negocio, debemos crear un diagrama de objetos, luego crear la clase (son clases creadas para apoyo nomás, no son las clases finales del sistema), luego instanciarla

- De Business Entity a Entity para al final poner tener las clases reales del software

- En entidades de negocio es necesario poner las clases y luego instanciarlas... en el modelo de Trabajadoers de Negocio, no es necesario crear las clases... solo se ponen objetos.
- Se puede subir los archivos de Enterprise Arquitect al subversion... leer esto
==
Precisiones:
El estereotipo es para los elementos, y es obligatorio en todos los diagramas y puede aparecer gráficamente o escrito.
El actor es una clase
Nunca poner BusinessWorker en un diagrama de Casos de Uso!
En las casos de uso no va la secuencia
==
Para el trabajo:
- Power Builder puede ser usado orientado a objetos? Sí... leer por qué
- Se puede subir los archivos de Enterprise Arquitect al subversion... leer esto
- Debo llegar a una nueva implementación del Gestor con un avance de los diagramas con Enterprise Arquitect.

Analisis y Diseño Orientado a Objetos

La Crisis del Software

Casos del Dpto de vehiculos motorizados de California y el caso de American Airlines

Razones:
Base Inestable, documentos no están estandarizados, formatos diferentes... diseños incomprensibles
Fallas en el Manejo de riesgo, faltó plan de contingencia, no planteó estrategia... y ante los problemas, no hay acción.
La complejidad del SW. Coplejidad en la lógica, complejidad en los procesos de negocio que conllevan a procesos automatizados complejos.

Soluciones:

• Buen análisis y Diseño, RUP tiene contemplado todas las herramientas para esto.
• Conservar un modelado sencillo. Programación lo más sencilla posible
• Usar un lenguaje de modelamiento común
• Compatible con diversas herramientas, no siempre tenemos las herramientas con las licencias... es mejor exportar los documentos a forma libre o estándar.

UML es necesario porque es un lenguaje estandarizado que permite graficar el sistema desde todas las perspectivas, por dentro y por fuera.. en cada evento, cada botón, cómo se registra en la base de datos, qué componentes salen producto de esa implementación y cómo se va a desplegar la aplicación.

Así como vamos a picar nuestras paredes y suelos de casa para poner el gas natural cuando no lo contemplamos en los planos, así también parcharemos los sistemas a la mala cuando tengamos que poner nuevas funcionalidades en nuestras aplicaciones.

Para lograr esto el concepto de orientación a objetos es muy útil, podremos armar el sistema como armando un rompecabezas.

Los objetos son comunes en la realidad, al nacer la RENIEC nos exige registrar a cada bebe. Así se reconoce la individualidad de cada persona. Y a su vez necesita información específica de cada uno, no quieren saber nuestro signo zodiacal o tipo de sangre, ellos necesitan los nombres, apellidos, fecha de nacimiento, y algunos datos más. No todos, solo algunos datos. Una universidad pide otro tipo de información, y así cada realidad exige distintos datos del objeto.

Un objeto posee características y comportamiento propios, únicos e inconfundibles.

Un buen análisis buscará encontrar esos elementos que lo hacen único e inconfundible.

Nunca asumir nada, siempre hay que analizar y preguntar siempre para conocer la identidad de un objeto.

Siempre observar las reglas de negocio preguntando

Los objetos tienen dos elementos: Atributos y Operaciones.

Los estados son valores de los atributos: Prendido, Apagado, Activo, Inacivo, Casado, Soltero, Aprobado, Desaprobado...

Siempre que vamos a hacer un sistema, se pregunta el alcance, para qué es el sistema y deben decirme qué atributos usar. Sino, corremos el riesgo de asumir.

==

Ejercicio: Hemos resaltado los objetos de este enunciado:

Juan Pérez es profesor del curso de Ingeniería de software dictado en la Escuela de Sistemas de la Facultad de Sistemas de la Universidad Peruana de Ciencias Aplicadas, también lo dicta en la escuela de sistemas de la Facultad de Sistemas de la UNI. Juan Pérez es profesor contratado en la UNI, pero es profesor nombrado en la Universidad. Es profesor principal en la UNI y es profesor asociado en la Universidad Peruana de Ciencias Aplicadas. Nació en Arequipa pero actualmente vive en Lima.

Pedro Alegría ingresa su código de estudiante al sistema de Reserva de cursos, el sistema le pregunta por el semestre a matricularse y este le indica que corresponde al semestre 2003-02, luego elige de la lista de horarios existentes, el horario nocturno.

De una lista de cursos disponibles, Pedro elige Inglés Básico, Electrónica Digital y Algoritmos Matemáticos. Como cursos electivos escoge Teoría de la Música y Programación en C++.

El sistema de Reservas de Cursos determina que los datos son conformes y le imprime el comprobante N° 0015264 para que se acerque al departamento de Caja puesto que internamente se acaba de enviar sus datos al sistema de Cobranzas para su proceso.

==

Programación Orientada a Objetos (características de objetos)

• Abstracción
• Encapsulamiento
• Cliente Servidor
• Jerarquía (dependencia) de dos tipos: Generalización (herencia) y Agregación (agrupamiento)
• Polimorfismo, una entidad que puede tomar diversas formas
• Modularidad, subdividir en partes más pequeñas para darles independencia
• Persistencia, capacidad de poder almacenarse en un lugar fijo para poder existir.

Clases

Agrupaciones de objetos con características y comportamientos similares. 

• Guía de estilo que recomienda RUP:
• Usar sustantivo singular
• Empezar con mayúscula
• No usar subrayado (los subrayado se usan en objetos, no en clases)
• Los nombres compuestos se escriben juntos.

Graficando:

Objeto:

Los objetos tienen los nombres subrayados

==
Ejercicio: se han  resaltado las clases en el siguiente enunciado:

En la base de datos de la Universidad Peruana de Ciencias Aplicadas, se representan datos sobre estudiantes y profesores. Para los estudiantes, se representa el apellido, edad, sexo, ciudad y provincia de nacimiento, ciudad y provincia de residencia de sus familias, lugares y provincias donde vivieron antes (con el lapso que vivieron en cada uno), cursos que han aprobado, con nombre, código, profesor, nota y fecha. Aunque para el caso de Alicia Fernández fue difícil registrar el lugar de residencia de sus padres porque es huérfana y su familia actual no recordaba ese dato.

Asimismo, se representan los cursos a los que un alumno asiste en la actualidad y, para cada uno, día, sitios y horas de dictado de las clases (cada curso se imparte a lo sumo una vez en un día).

Para estudiantes graduados, se representa el nombre del consejero y el número total de créditos en el último año. El Ing. Rubén De la Cruz es consejero de esta universidad por más de tres años consecutivos pero dejo de ser docente el ciclo pasado.

Para estudiantes de doctorado, se representa el título y área de investigación de sus tesis. Para los maestros, se representa el apellido, edad, lugar y provincia de nacimiento, nombre del departamento académico al que pertenecen, número de teléfono, título, situación y temas de investigación.

Algunos temas de investigación, como la Exportación de Espárragos, ya están prohibidos por haberse saturado el número de tesis presentadas.

==

Por qué fracasan los Proyectos de Software

Nos ponen algunas pero tienen maneras de resolverlas, RUP ofrece mejores practicas

Aplicar una metodología pero apliquémosla bien: una metodología y un lenguaje común

=====

Reflexiones para el trabajo:

- El Gestor no es Modulado... se puede hacer algo con esto?

- Control de versionamiento siempre