qwertyuiopasdfghjklzxcvbnmqw

ertyuiopasdfghjklzxcvbnmqwert
yuiopasdfghjklzxcvbnmqwertyui
opasdfghjklzxcvbnmqwertyuiopa
sdfghjklzxcvbnmqwertyuiopasdf
ghjklzxcvbnmqwertyuiopasdfghj
klzxcvbnmqwertyuiopasdfghjklz
xcvbnmqwertyuiopasdfghjklzxcv
bnmqwertyuiopasdfghjklzxcvbn
mqwertyuiopasdfghjklzxcvbnmq
wertyuiopasdfghjklzxcvbnmqwe
rtyuiopasdfghjklzxcvbnmqwerty
uiopasdfghjklzxcvbnmqwertyuio
pasdfghjklzxcvbnmqwertyuiopas
dfghjklzxcvbnmqwertyuiopasdfg
hjklzxcvbnmqwertyuiopasdfghjk





INSTITUTO TECNOLGICO SUPERIOR DE
TEPEACA
(Escuela)

INGENIERIA EN SISTEMAS COMPUTACIONALES
(Carrera)

ING. CLAUDIA NELLY LPEZ MORALES
(Docente)

DESARROLLO DE PROYECTOS DE SOFTWARE
(Materia)

TAREA 1; ARQUITECTURA DE 4+1 VISTAS
(Tarea)


EQUIPO 4
INTEGRANTES:

SNCHEZ YEZ EMMA
CANIZO GUZMAN DMASO
HERNANDEZ BERNAL ANTONIO MARGARITO


FEBRERO-JUNIO 2013
(Periodo Escolar)
La arquitectura del software se trata de abstracciones, de descomposicin y composicin, de
estilos y esttica.
Tambin tiene relacin con el diseo y la implementacin de la estructura de alto nivel del software.
Los diseadores construyen la arquitectura usando varios elementos arquitectnicos elegidos
apropiadamente.
Estos elementos satisfacen la mayor parte de los requisitos de funcionalidad y performance del
sistema, as como tambin otros requisitos no funcionales tales como confiabilidad, escalabilidad,
portabilidad y disponibilidad del sistema.

El modelo de 4+1 vistas fue desarrollado para remediar este problema. El modelo 4+1 describe la
arquitectura del software usando cinco vistas concurrentes.
Como se muestra a continuacin:



- La vista lgica describe el modelo de objetos del diseo cuando se usa un mtodo de
diseo orientado a objetos. Para disear una aplicacin muy orientada a los datos, se
puede usar un enfoque alternativo para desarrollar algn otro tipo de vista lgica, tal como
diagramas de entidad-relacin.
- La vista de procesos describe los aspectos de concurrencia y sincronizacin del diseo.
- La vista fsica describe el mapeo del software en el hardware y refleja los aspectos de
distribucin.
- La vista de desarrollo describe la organizacin esttica del software en su ambiente de
desarrollo.

La arquitectura lgica apoya principalmente los requisitos funcionales lo que el sistema debe
brindar en trminos de servicios a sus usuarios. El sistema se descompone en una serie de
abstracciones clave, tomadas (principalmente) del dominio del problema en la forma de objetos o
clases de objetos. Aqu se aplican los principios de abstraccin, encapsulamiento y herencia.

Un proceso es una agrupacin de tareas que forman una unidad ejecutable. Los procesos
representan el nivel al que la arquitectura de procesos puede ser controlada tcticamente
(comenzar, recuperar, reconfigurar, y detener). Adems, los procesos pueden replicarse para
aumentar la distribucin de la carga de procesamiento, o para mejorar la disponibilidad.

La vista de desarrollo se centra en la organizacin real de los mdulos de software en el ambiente
de desarrollo del software. El software se empaqueta en partes pequeas bibliotecas de programas
o subsistemas que pueden ser desarrollados por uno o un grupo pequeo de desarrolladores. Los
subsistemas se organizan en una jerarqua de capas, cada una de las cuales brinda una interfaz
estrecha y bien definida hacia las capas superiores.

La arquitectura fsica toma en cuenta primeramente los requisitos no funcionales del sistema tales
como la disponibilidad, confiabilidad (tolerancia a fallas), performance (rendimiento), y
escalabilidad. El software ejecuta sobre una red de computadores o nodos de procesamiento (o tan
solo nodos). Los variados elementos identificados redes, procesos, tareas y objetos requieren ser
mapeados sobre los variados nodos. Esperamos que diferentes configuraciones puedan usarse:
algunas para desarrollo y pruebas, otras para emplazar el sistema en varios sitios para distintos
usuarios.
Escenarios: son todas las partes juntas:
Los elementos de las cuatro vistas trabajan conjuntamente en forma natural mediante el uso de un
conjunto pequeo de escenarios relevantes instancias de casos de uso ms generales para los
cuales describimos sus scripts correspondientes (secuencias de interacciones entre objetos y entre
procesos. Los escenarios son de alguna manera una abstraccin de los requisitos ms
importantes. Su diseo se expresa mediante el uso de diagramas de escenarios y diagramas de
interaccin de objetos.








CLONCUCIN:

El modelo 4+1 vistas describe la arquitectura del software, y se relaciona con el diseo e
implantacin de alto nivel ya que tambin cuenta con requisitos no funcionales como: fiabilidad,
escalabilidad, portabilidad y disponibilidad.

Las 5 vistas de la arquitectura son;
- Vista lgica: se refiere a un modelo de objetos del diseo orientado a objetos como son;
objetos, clases, entidades y una relacin, para obtener datos precisos.
- Vista de procesos: describe la agrupacin de tareas ejecutables, una concurrencia y la
sincronizacin.
- Vista fsica: describe un mapeo de software y hardware y refleja una distribucin.
- Vista de desarrollo: organiza y describe el diagrama de mdulos en las relaciones en los
componentes de desarrollo.
- Escenario: trabaja conjuntamente con las 4 vistas anteriores, es una abstraccin de los
requisitos ms importantes.
REFERENCIAS BIBLIOGRAFICAS:

- Paul Clements. From Domain Model to Architectures. In A. Abd-Allah et al., editor, Focused
Workshop on Software Architecture, pages 404420, 1994.

- Gregory D. Abowd, Robert Allen, and David Garlan. Using Style to Understand Descriptions
of Software Architecture. In Proceedings of the First ACM SIGSOFT Symposium on
Foundations of Software Engineering, pages 920, Los Angeles, California, USA, 1993.

- David Garlan. Proceedings of the first internal workshop on architectures for software
systems. Technical Report CMU-CS-TR-95-151, Carnegie Mellon University, Pittsburgh,
1995.




INSTITUTO TECNOLGICO SUPERIOR DE TEPEACA
(Escuela)

INGENIERIA EN SISTEMAS COMPUTACIONALES
(Carrera)

DESARROLLO DE PROYECTOS DE SOFTWARE
(Materia)

ING. CLAUDIA NELLY LPEZ MORALES
(Docente)


TAREA 2;
ASOCIACIONES Y DIAGRAMAS
(Tarea)


EQUIPO 4

INTEGRANTES:

SNCHEZ YEZ EMMA
CANIZO GUZMAN DMASO
HERNANDEZ BERNAL ANTONIO MARGARITO


FEBRERO-JUNIO 2013
(Periodo Escolar)
ASOCIACIONES DE AGREGACIN O COMPOSICIN
Un caso particular de asociacin esttica, es cuando se encuentra que un objeto no slo est
asociado con otro, sino que adems uno es parte del otro. Este tipo de situacin se le llama
asociacin de agregacin.
La agregacin podemos establecerla en dos tipos: por composicin y por agregacin simple. En la
primera, los objetos y la asociacin se dieron simultneamente y cuando desaparezca un objeto, el
otro tambin desaparecer, as como la asociacin. Por lo regular se da cuando modelamos un
objeto como propiedad de otro objeto como se muestra en la figura siguiente.

La agregacin simple es la ms comn y se da cuando tenemos documentos, tales como facturas,
rdenes de entrada de almacn, recibos de pago, etc. Ya que el documento es el objeto central y
tiene una serie de caractersticas con cierto grado de opcionalidad, que hacen no necesiten estar
los dos para que la agregacin.

En general es conveniente indicar las asociaciones de agregacin pues sugieren que las
operaciones de mantenimiento a esos objetos tienen que hacerse dentro de una misma
transaccin, lo cual ayuda a identificar la complejidad de los modelos de objetos que se estn
obteniendo. Siempre ser ms fcil dar mantenimiento a una familia de objetos que a dos o ms
familias de objetos como lo sugieren las asociaciones de agregacin.

DIAGRAMACIN
El propsito de este diagrama es el de representar los objetos fundamentales del sistema, es decir
los que percibe el usuario y con los que espera tratar para completar su tarea en vez de objetos del
sistema o de un modelo de programacin.




DIAGRAMA DE CLASES:
Los diagramas de clases proporcionan una perspectiva esttica del sistema (representan su diseo
estructural), son los bloques de construccin ms importantes de cualquier sistema orientado a
objetos y es una descripcin de un conjunto de objetos que comparten los mismos atributos,
operaciones, relaciones y semntica.



Diagrama de clases.
Yv oti|uto co uvo toticooo oc uvo _ooc iocvti|i_ooo _ov uv vo|c, uuc oco_i|c uv ovo oc
=ooco uuc tucocv too oo ivotov_ioo oc o toticooo.
Una operacin es la implementacin de un servicio que puede ser requerido a cualquier objeto de
la clase para que muestre un comportamiento, En otras palabras, una operacin es una
abstraccin de algo que se puede hacer a un objeto y que es compartido por todos los objetos de
la clase.

DIAGRAMA DE CASOS DE USO:
Muestra la relacin entre los actores y los casos de uso del sistema. Representa la funcionalidad
que ofrece el sistema en lo que se refiere a su interaccin externa. En el diagrama de casos de uso
se representa tambin el sistema como una caja rectangular con el nombre en su interior.
Los casos de uso estn en el interior de la caja del sistema, y los actores fuera, y cada actor est
unido a los casos de uso en los que participa mediante una lnea.

Un actor en un diagrama de casos de uso representa un rol que alguien puede estar jugando, no
un individuo particular por lo tanto puede haber personas particulares que puedan estar usando el
sistema de formas diferentes en diferentes ocasiones: socio de biblioteca y bibliotecario.
Caso de uso: Es una tarea que debe poder llevarse a cabo con el apoyo del sistema que se est
desarrollando. Se representan mediante un vulo.

DIAGRAMA DE INTERACIN:
Son diagramas que describen como grupos de objetos colaboran para conseguir algn fin. Estos
diagramas muestran objetos, as como los mensajes que se pasan entre ellos dentro del caso de
uso.
En los diagramas de interaccin se muestra un patrn de interaccin entre objetos. Hay dos tipos
de diagrama de interaccin, ambos basados en la misma informacin, pero cada uno enfatizando
un aspecto particular: Diagramas de Secuencia y Diagramas de Colaboracin.
Diagrama de secuencia: muestra una interaccin ordenada segn la secuencia temporal
de eventos. Se muestra los objetos participantes en la interaccin y los mensajes que
intercambian ordenados segn su secuencia en el tiempo

Diagrama de colaboracin: muestra una interaccin organizada basndose en los objetos
que toman parte en la interaccin y los enlaces entre los mismos. muestran las relaciones
entre los roles de los objetos. La secuencia de los mensajes y los flujos de ejecucin
concurrentes deben determinarse explcitamente mediante nmeros de secuencia.


El diagrama de Colaboracin muestra a una serie de objetos con los enlaces entre los mismos, y
con los mensajes que se intercambian dichos objetos. Los mensajes son flechas que van junto al
enlace por el que circulan, y con el nombre del mensaje y los parmetros (si los tiene) entre
parntesis.

DIAGRAMA DE ESTADOS:

Los diagramas de estado muestran el conjunto de estados por los cuales pasa un objeto durante
su vida en una aplicacin en respuesta a eventos (por ejemplo, mensajes recibidos, tiempo
rebasado o errores), junto con sus respuestas y acciones. Tambin ilustran qu eventos pueden
cambiar el estado de los objetos de la clase. Normalmente contienen: estados y transiciones.
Como los estados y las transiciones incluyen, a su vez, eventos, acciones y actividades, vamos a
ver primero sus definiciones.
En cuanto a la representacin, un diagrama de estados es un grafo cuyos nodos son estados y
cuyos arcos dirigidos son transiciones etiquetadas con los nombres de los eventos.
Un estado se representa como una caja redondeada con el nombre del estado en su interior. Una
transicin se representa como una flecha desde el estado origen al estado destino.
La caja de un estado puede tener 1 o 2 compartimentos. En el primer compartimento aparece el
nombre del estado. El segundo compartimento es opcional, y en l pueden aparecer acciones de
entrada, de salida y acciones internas.










CONCLUCIN:

Asociacin e agregacin podremos decir que, es cuando se encuentra un objeto y no slo est
asociado con otro, sino que adems uno es parte del otro, en si todos tiene relacin.
La agregacin se divide en dos tipos: por composicin y por agregacin:
- Agregacin: se expresa con un rombo en donde se encuentra la clase, a la que se le estn
agregando objetos.
- Composicin: se denota con el rombo slido, mientas que la agregacin simple es con el
rombo vaco.
La diagramacin es la representacin de los objetos, un plan estructurado y jerarquizado.
Y se dividen en 6 modelos de UML:

- Diagrama de Estructura Esttica: son los bloques de representacin.
- Diagrama de Casos de Uso: es la relacin entre actores y objetos, que es un
comportamiento de un sistema.
- Diagrama de Secuencia:
- Diagrama de Colaboracin o interaccin: describen como grupos de objetos ayudan para
conseguir algn fin.
- Diagrama de Estados: es el cambio de estado en la ejecucin del programa.
- Diagrama de clases: se muestran clases, mtodos, atributos, nombres y el rol entre las
clases.


















REFERENCIAS BIBLIOGRAFICAS:

Booch, Grady, El Lenguaje Unificado de Modelado. Addison Wesley Iberoamericana, 1999.
Sommerville, Ian. Ingeniera de Software. Prentice Hall. 2001.
Pressman Roger S. Ingeniera del Software, 5/E. Mc.Gaw-Hill. 2001.










INSTITUTO TECNOLGICO SUPERIOR DE TEPEACA
(Escuela)

INGENIERIA EN SISTEMAS COMPUTACIONALES
(Carrera)

DESARROLLO DE PROYECTOS DE SOFTWARE
(Materia)

ING. CLAUDIA NELLY LPEZ MORALES
(Docente)


TAREA 3;
1.3 DIAGRAMACIN
(Tarea)


EQUIPO 4

INTEGRANTES:

SNCHEZ YEZ EMMA
CANIZO GUZMAN DMASO
HERNANDEZ BERNAL ANTONIO MARGARITO


FEBRERO-JUNIO 2013
(Periodo Escolar)
1.3 Diagramacin
Qu es UML?
UML (Unified Modeling Language) es un lenguaje que permite modelar, construir y
documentar los elementos que forman un sistema software orientado a objetos.
El UML nos permite mediante diagramas, plasmar de una forma detallada e inteligible la
solucin al problema planteado.
Los diagramas tienen como objetivo presentar diversas perspectivas de un sistema. A esto se le
llama Modelo. El modelo UML de un sistema es similar a un modelo a escala de un edificio junto
con la interpretacin del artista del edificio. Tenemos que tener en cuenta que un modelo UML
describe lo que supuestamente har un sistema, pero no dice cmo implementar dicho sistema.
Los diagramas expresan grficamente partes de un modelo
















Diagrama de Casos de Uso
Use Case
Diagrams
Use Case
Diagrams
Diagramas de
Casos de Uso
Scenario
Diagrams
Scenario
Diagrams
Diagramas de
Colaboracin
State
Diagrams
State
Diagrams
Diagramas de
Componentes
Component
Diagrams
Component
Diagrams
Diagramas de
Distribucin
State
Diagrams
State
Diagrams
Diagramas de
Objetos
Scenario
Diagrams
Scenario
Diagrams
Diagramas de
Estados
Use Case
Diagrams
Use Case
Diagrams
Diagramas de
Secuencia
State
Diagrams
State
Diagrams
Diagramas de
Clases
Diagramas de
Actividad
Diagrama de Clases
Diagrama de Objetos
Diagramas de Comportamiento
Diagrama de Estados
Diagrama de Actividad
Diagramas de Interaccin
Diagrama de Secuencia
Diagrama de Colaboracin
Diagramas de implementacin
Diagrama de Componentes
Diagrama de Despliegue
Diagramas de casos de uso



Nombre de caso de uso
Actor
Relacin o Flujo de informacin
Diagramas de clases











Diagramas de estados












Nombre de la clase
Relacin
Nombre de la clase
Atributos
Actividades
Nombre del estado
Punto inicial de un estado
Relacin o Flujo de informacin
Punto Final de un estado
Diagramas de secuencia








Nombre del objeto
Lnea de vida de un objeto
Mensaje sncrono
:Nombre
Mensaje simple
Mensaje asncrono
Activacin
Diagramas de colaboracin











Nombre del objeto
Relacin entre Objetos
:Nombre
Flujo de envo de mensaje
Diagramas de actividades




















Actividad
Punto inicial
Flujo de informacin
Punto Final
Envo de indicacin
Recepcin de indicacin

Decisin
Diagramas de componentes




















Componente
Relacin
Clases
Interfaz


Conclusin

1. Definir el Plan-Borrador.
2. Crear el Informe de Investigacin Preliminar.
3. Definir los Requisitos.
4. Registrar Trminos en el Glosario. (Continuado en posteriores fases)
5. Implementar un Prototipo. (Opcional)
6. Definir Casos de Uso (de alto nivel y esenciales).
7. Definir el Modelo Conceptual-Borrador. (Puede retrasarse hasta una fase posterior)
8. Definir la Arquitectura del Sistema-Borrador. (Puede retrasarse hasta una fase posterior)
9. Refinar el Plan.
La puesta en marcha del sistema en el entorno previsto de uso.
La fase de Construir es la que va a consumir la mayor parte del esfuerzo y del tiempo en un
proyecto de desarrollo. Para llevarla a cabo se va adoptar un enfoque evolutivo, tomando en cada
iteracin un subconjunto de los requisitos (agrupados segn casos de uso) y llevndolo a travs del
diseo de alto y bajo nivel hasta la implementacin y pruebas.
El sistema va creciendo incrementalmente en cada ciclo. Con esta aproximacin se
consigue disminuir el grado de complejidad que se trata en cada ciclo, y se tiene pronto en el
proceso una parte del sistema funcionando que se puede contrastar con el usuario/cliente.
Bibliografa
- Mari Carmen Otero Vidal Dpto. de Lenguajes y Sistemas Informticos


RUBICA PARA
TAREAS
Valor
Cumple
/ No
observaciones
Cumple
Portada 10% 9

Ortografa 10% 9

Contenido 40% 35
Desarrollo y
Coherencia 30% 24

Presentacin 10% 9

Calificacin 100% 86

+ 5 ptos de practica

91


TAREA DEBE
CONTENER
CUMPLE / NO
CUMPLE observaciones
Portada si

Contenido si le falto otros temas
Resumen si 9

Conclusin NO No muy claro
Ref Bibliografica si