martes, 27 de noviembre de 2012

DEFINICIÓN DE DIAGRAMA DE SECUENCIA


Diagrama de secuencia

En un diagrama de secuencia ponemos varios de los objetos o clases que forman parte de nuestro programa y ponemos qué llamadas van haciendo unos a otros para realizar una tarea determinada.
Hacemos un diagrama de secuencia por cada caso de uso o para una parte de un caso de uso (lo que llamo sub caso de uso). En nuestro ejemplo de ajedrez, podemos hacer diagramas de secuencia para "jugar partida" o bien para partes de "jugar partida", como puede ser "mover pieza".
El detalle del diagrama depende de la fase en la que estemos, lo que pretendamos contar con el diagrama y a quién. En una primera fase de diseño podemos poner clases grandes y ficticias, que representen un paquete/librería o, si nuestro programa está compuesto por varios ejecutables corriendo a la vez, incluso clases que representen un ejecutable.
Si estamos en una fase avanzada, estamos diseñando el programa y queremos dejar bien atados los detalles entre dos programadores, que cada uno va a programar una de las clases que participan, entonces debemos posiblemente ir al nivel de clase real de codificación y método, con parámetros y todo, de forma que los programadores tengan claro que métodos van a implementar, que deben llamar de la clase del otro, etc. Incluso si es un diagrama para presentar al cliente, podemos hacer un diagrama de secuencia en el que sólo salga el actor "jugador" y una única clase "juego ajedrez" que representa nuestro programa completo, de forma que el cliente vea qué datos y en qué orden los tiene que meter en el programa y vea qué salidas y resultados le va a dar el programa.


El siguiente puede ser un diagrama de secuencia de nuestro ejemplo del ajedrez a un  nivel de diseño muy preliminar





Aquí ya hemos decidido que vamos a hacer tres librerías/paquetes, una para la interface de usuario, otra para contener el tablero y reglas del ajedrez (movimientos válidos y demás) y otra para el algoritmo de juego del ordenador. Hemos puesto una clase representando cada uno de los paquetes y hemos representado el caso de usa "mover pieza".
En el diagrama de secuencia no se ponen situaciones erróneas (movimientos inválidos, jaques, etc.) puesto que poner todos los detalles puede dar lugar a un diagrama que no se entiende o difícil de leer. El diagrama puede acompañarse con un texto en el que se detallen todas estas situaciones erróneas y particularidades. Si se quiere dejar muy claro que un determinado error se contempla, por ejemplo, un movimiento no válido por el usuario, entonces sí se puede poner en el diagrama de secuencia, siempre que no "embarulle" demasiado.
En este diagrama sencillo ya vamos dejando algunas cosas claras, como por ejemplo, que la interface de usuario hace llamadas y, por tanto, ve a los otros dos, mientras que algoritmo sólo ve al tablero/reglas. El tablero/reglas aparentemente ve a la interface de usuario, pero no nos interesa si seguimos un patrón modelo-vista-controlador, así que ese "Refresca pantalla" lo implementaremos con un patrón observador, pero eso son detalles que quizás no vienen al caso ahora.




lunes, 19 de noviembre de 2012

¡¡ Definición y ejemplo de Diagrama!!


Diagrama de clases


Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro.
Representación de: - Requerimientos en entidades y actuaciones. - La arquitectura conceptual de un dominio - Soluciones de diseño en una arquitectura - Componentes de software orientados a objetos.
El diagrama de clases incluye mucha más información como la relación entre un objeto y otro, la herencia de propiedades de otro objeto, conjuntos de operaciones/propiedades que son implementadas para una interfaz gráfica.







martes, 13 de noviembre de 2012

NORMAS PARA EL DESARROLLO DE UN PROYECTO


SUGERENCIAS PARA EL DESARROLLO DEL PROYECTO DE AULA


1. JUSTIFICACIÓN: A qui colocar el porqué se creó el proyecto, que beneficio trae para la empresa.
Ejemplo: Este software será de utilidad para los investigadores porque en ellos encontraran bases teóricas para ayuda con base a un proyecto.
Este proyecto es importante para tecnar porque…………………………………

2. EL PROBLEMA: Es hablar única y exclusivamente del problema, va en base a la justificación.

3. BASES TEÓRICAS: Meter emprendimiento etc. Por ejemplo hablar de la ingeniería de software,
INGENIERÍA DE SOFTWARE: Hacer un relato de lo que es la ingeniería de software pero ojo utilizando libros, Internet etc.

4. METODOLOGÍA:
TIPO: Es la forma de cómo nosotros realmente vamos adelantar la información.
MÉTODO: Instrumentos con los que vamos a nutrir este tipo de información, trabajar con los métodos cualitativos y cuantitativos.
ENFOQUE: Sera llamado proyectivo porque hay que dejar en especie de una mono grafía.

5. FUENTES:
PRIMARIAS: Son los departamentos o centros en donde yo investigue, son las investigaciones propias
SECUNDARIAS: Son las ayudas del profesor, revistas, periódicos, libros etc.

6. RECURSOS: Hay 4 tipos de recursos que son:
1. Recursos humanos: Eso somos nosotros mismos ósea los integrantes del grupo 
  
2. Recursos tecnológicos: Es el hardware que nosotros necesitamos para trabajar el proyecto 

3. Recursos financieros: Propios o pesos

4. Recursos institucionales: Son los que nos provee la institución para poder hacer los proyectos como: Las salas de computo, Bibliotecas laboratorios etc.

5. Presupuesto:

6 Crono grama: Microsoft proyec  y buscar plantillas para proyectos de software.

7. BIBLIOGRAFIA: Esta compuesta de 2 formas que son:
Cibergrafia y Bibliografía
Nota: Ahí que colocarlas todas dos.

8. OBJETIVOS ESPECÍFICOS  Son los pasos del ciclo de vida que nosotros escogimos. Son 5 que todos estos conllevan a la aplicación de los objetivos generales.

ANTECEDENTES: Son aquellos software que pudimos observar para el diseño del de nosotros.

4to CAPITULO: Es la materialización del proyecto.
4.1 Es el primer objetivo especifico: En donde van todas las entrevistas que hicimos a que conclusión llegamos, el problema etc.
4.2 ANÁLISIS: Todos los casos de usos, diagrama de clases y diagrama de secuencia.
4.3 DISEÑO: Pantallazos e infraestructura a qui entra sistema operativo ósea el tipo de software que  utilizamos como por ejemplo: Cliente servidor, entonces entraría la parte de redes.
4.4 DESARROLLO: A qui van todas las fases del porque de la herramienta del desarrollo y una pequeña fase el código.
4.5  MANUAL DE USUARIOS: Esto se coloca como anexos y además un plan de contingencia, ósea que pasaría buscando la prevención de las cosas.
Como anexos: Las cosas que nos ayudaron para armar el proyecto.
5. CONCLUSIÓN: Podemos concluir……………….
La conclusión se basa en todos los objetivos específicos, ósea la definición y terminación  de cada objetivo específico.
NOTA: Por cada objetivo especifico hacer una conclusión.
A DEMAS TENER EN CUENTA QUE: Primero va la  conclusión y luego los anexos.

6. RECOMENDACIONES: Recomendamos que  aquellos estudiantes que quieran seguir en el proyecto se empapen con x o tal punto y vallan a la empresa y sigan investigando para ir mejorando.

7. BIBLIOGRAFIA
7.2 CIBERGRAFIA
8. ANEXOS