Universidad Tecnolgica de Campeche

T.S.U. Tecnologas de la Informacin y Comunicacin.

rea: Sistemas Informticos.

Asignatura:
Ingeniera de Software I

Nombre del docente:

Jess Humberto Murillo Flores.

Nombre del alumno:

Heberet Martnez Snchez.

Grado: 4

Grupo: B

Periodo: Septiembre-Diciembre 2015

San Antonio Crdenas, Carmen, Campeche; Diciembre del 2015

INGENIERA DE SOFTWARE I

Competencias

Objetivo de
aprendizaje

Implementar sistemas de informacin de

calidad, a travs de tcnicas avanzadas de
desarrollo de software para eficientar los
procesos de las organizaciones.
Implementar
y
administrar
sistemas
manejadores de bases de datos acorde a los
requerimientos de informacin de la
organizacin.

El alumno elaborar el modelado de un

sistema
de
informacin
empleando
metodologas, tcnicas y herramientas para
construir una propuesta de solucin a un
problema determinado.

En esta unidad nos dimos a la tarea de poder analizar y comprender los temas
que abarca dicha unidad en el cual lleva como nombre Metodologas de
Desarrollo de Software ya que este es un marco de trabajo para estructurar,
planificar y controlar el proceso de desarrollo en sistemas de informacin.
Tambin podemos mencionar que se clasifican dichas metodologas como
pueden ser el Modelo de cascada en el cual el desarrollo se ve como una serie
de escalones descendientes a travs de las distintas fases; la Metodologa de
prototipos, se conoce as a las actividades de creacin de prototipos durante el
desarrollo de software, los prototipos son versiones incompletas del producto
que se va a ser desarrollado; el Espiral es bsicamente consiste en una serie de
ciclos que se repiten en forma de espiral, comenzando desde el centro; el RAD
comprende el desarrollo iterativo, la construccin de prototipos y el uso de
herramientas CASE entre otras metodologas.

As mismo, cabe destacar que tambin incluye lo que son las ventajas y
desventajas que tienen cada Metodologas de Desarrollo de Software, ya que
comprendimos las ventajas que de una manera, sus caractersticas se adaptan
a nuestro trabajo dependiente que tipo de proyecto estamos trabajando y las
desventajas que a pesar de que nos ayudaran hay puntos que nos perjudicaran
en gran manera debido a sus desventajas,

Universidad Tecnolgica de Campeche

T.S.U. Tecnologas de la Informacin y Comunicacin.
rea: Sistemas Informticos.
Asignatura: Ingeniera de Software I.

Nombre del docente:

Jess Humberto Murillo Flores.

Unidad II. Administracin de Requerimientos.

Actividad:
Prctica (Resultado de aprendizaje)

Integrantes:
Heberet Martnez Snchez.
Maritza Gernimo Snchez.
Zurisadai May Daz.
Cindy del Carmen Snchez Salvador.

Grado: 4

Grupo: B

Periodo: Septiembre-Diciembre 2015

San Antonio Crdenas, Carmen, Campeche a 5 de octubre de 2015.

INTRODUCCIN

El proyecto Diccionario Espaol-Maya es una aplicacin para la ayuda de la

lengua Maya en la cual podrn ingresar estudiantes y/o maestros como
registrarse.
Esta aplicacin solo es para la Intranet, es decir que solo estudiantes y maestros
de la Universidad Tecnolgica de Campeche podrn ingresar y registrarse.
Para el proyecto se analizaran los requerimientos, como funcionales y no
funcionales. As como tambin el alcance que queremos lograr para nuestro
proyecto y las limitaciones que tendr al usar la aplicacin.
Cabe mencionar que los ingenieros de software trabajan con los clientes y
usuarios finales del sistema para determinar el dominio de la aplicacin, como
tambin que servicios debe proporcionar el sistema, el rendimiento requerido del
sistema, las restricciones de hardware, entre otros.
As mismo, podemos decir que se analizara el tema de estudio de factibilidad ya
que ms adelante se menciona basado a nuestro proyecto que es el de
Diccionario Espaol-Maya, aplicndolo a la factibilidad tcnica, factibilidad
operativa y factibilidad econmica.

Administracin de Requerimientos.

A) Requerimientos Funcionales.
Podrn registrarse los estudiantes y/o profesores que ingresen a la
intranet de la UTCAM ya que estar en ella, si no ests registrado
podr loguearse.
La aplicacin a desarrollar ser una aplicacin de tipo web en esta
alojara y almacenara palabras en espaol a maya y viceversa.

B) Requerimientos no Funcionales.

Como requerimientos no funcionales tenemos los siguientes puntos:

Comprobabilidad: como prueba de nuestro sistema servir estar al
alcance de todos para que no puedan conocer y observar tanto alumnos
como profesores.
Disponibilidad: estar disponible a los usuarios las veces que lo deseen
consultar.
Extensibilidad: este proyecto o aplicacin podr extenderse a la manera
que el usuario lo necesite, puesto que de esta manera el usuario podr
agregar palabras nuevas a este diccionario para que si no estn pueda
agregarlas.
Escabilidad: podr registrar y guardar registros a un sin nmero de
personas a este diccionario ya que contara con una base de datos la cual
podr alojarlos a todos ellos.
Mantenibilidad: en dado caso que requerido un mantenimiento se le
realizara con la finalidad de nuevos requerimientos y/o corregir algn
defecto.

 Seguridad: ninguna persona ajena a este software podr tener acceso a

los datos y a la codificacin de la misma puesto que solo una persona
especfica podr tener acceso a ella por cuestiones de seguridad.
Usabilidad: mediante su uso podrn aprender y conocer el manejo del
mismo, como no olvidando el aprendizaje de nuestra lengua maya, a
travs de este didctico software.

C) Alcances y Limitaciones del proyecto.

Poder desarrollar un software en donde demos a conocer la importancia
de la lengua materna del estado de Campeche (Maya).
Nuestra aplicacin se encontrara en la intranet de la Universidad
Tecnolgica de Campeche (UTCAM) y as los estudiantes y los profesores
tengan acceso a ella.
Lograr un alcance a travs de nuestro software para que no se pierda la
lengua materna (Maya).
Nuestra aplicacin no estar en el internet debido a que ya existen varias
en la web.
No podr ser editada por algn usuario ajena a la misma, sino a aquel que
tenga acceso a la codificacin los datos de esta aplicacin.
No podr accesar a la aplicacin fuera del rea de la UTCAM

D) Estudio de Factibilidad

D.1: Factibilidad tcnica

Las herramientas a utilizar son:

Hardware:
1 Laptop

Software
1.-Navegador de internet (Google Chrome, Internet Explorer,
Firefox, etc.).
2-.SGBD (SQL Server 2014).
3.-Visual Basic.NET
D.2: Factibilidad econmica
Tiempo de anlisis:
30 das aproximadamente.
No con llevamos a ningn gastos ya que contbamos con
SGBD (SQL Server 2014) y Visual Basic.NET
D.3: Factibilidad Operativa

El proyecto Diccionario Espaol-Maya con llevar a la participacin de

4 integrantes que realizaran actividades como las siguientes:
Adquisicin de informacin.
Desarrollo de la aplicacin.
Diseo de la aplicacin.
Estructura de datos de la aplicacin.
Testeo de la aplicacin.
Pruebas de la aplicacin.
Instalacin e implementacin de la aplicacin.
Uso y Mantenimiento (en su debido caso).

CONCLUSIN

Para concluir con esta actividad podemos mencionar que analizamos distintos
puntos basado a la administracin de requerimientos ya que este tiene como
objetivo de comprender y controlar los requerimientos. Como tambin se
especificaron cules seran los requerimientos funcionales basados en nuestro
proyecto Diccionario Espaol-Maya ya que estos requerimientos describen la
funcionalidad o los servicios que se espera que el sistema proveer, de igual
manera se plasmaron los requerimientos no funcionales ya que estos son los
requerimientos que no se refieren directamente a las funciones especficas que
entrega el sistema, sino a las propiedades emergentes de este, como por
ejemplo la fiabilidad, la respuesta en el tiempo y la capacidad de
almacenamiento.

Cabe mencionar que se sealaron los alcances y limitaciones que tenemos como
estudiantes en la hora de hablar del proyecto que se est realizando ya que es
de suma importancia ya que estamos basndonos y queremos lograr un alcance
a travs de nuestro software para que no se pierda la lengua materna (maya) ya
que con el paso del tiempo esta se va a ir desapareciendo poco a poco.

As mismo, se aplica en la factibilidad tcnica la cual ah mencionamos lo que

son las herramientas que se utilizaran para nuestro proyecto, la factibilidad
operativa se refiere a todas aquellos recursos donde intervienen algn tipo de
actividad, podamos decir que son las actividades que se realizaran y como por
ltimo la factibilidad econmica que este se refiere a los recursos econmicos y
financieros necesarios para desarrollar o llevar a cabo las actividades o
procesos.

Diapositivas:

Resumen:

Universidad Tecnolgica De Campeche

T.S.U. Tecnologas de la Informacin y Comunicacin.

rea: Sistemas Informticos.

Asignatura:
Ingeniera Del Software

II Unidad
Administracin de Requerimientos

Actividad:
Investigacin

Docente: Jess Humberto Murillo Flores.

Integrantes Del Equipo

Cindy Del Carmen Snchez Salvador
Heberet Martnez Snchez
Maritza Gernimo Snchez
Zurisadai May Daz
Jhonny Martnez Jimnez

Grado: 4

Grupo: B

Cuatrimestre:
Septiembre - Diciembre

San Antonio Crdenas Carmen, Campeche; Septiembre 2015

Introduccin
Los requisitos una vez definidos necesitan ser validados. Es necesario asegurar
que el anlisis realizado y los resultados obtenidos de la etapa de definicin de
requisitos son correctos. Pocas son las propuestas existentes que ofrecen
tcnicas para la realizacin de la validacin y muchas de ellas consisten en
revisar los modelos obtenidos en la definicin de requisitos con el usuario para
detectar errores o inconsistencias.
El proceso de validacin de requisitos debe realizarse o de lo contrario se corre
el riesgo de implementar una mala especificacin, con el costo que eso conlleva
Los parmetros a comprobar por la especificacin son:
Validez: No basta con preguntar a un usuario, todos los potenciales
usuarios pueden tener puntos de vista distintos y necesitar otros
requisitos.
Consistencia: No debe haber contradicciones entre unos requisitos y
otros.
Completitud: Deben estar todos los requisitos. Esto es imposible en un
desarrollo iterativo, pero, al menos, deben estar disponibles todos los
requisitos de la iteracin en curso.
Realismo: Se pueden implementar con la tecnologa actual.
Verificabilidad: Tiene que existir alguna forma de comprobar que cada
requisito se cumple.

ndice

Introduccin ...............................................................................................................................62
Tema: Validacin De requisitos ..................................................................................................64
REVISIONES DE REQUERIMIENTOS .............................................................................................65
GESTION DE REQUERIMIENTOS .................................................................................................65
PLANIFICACION DE LA GESTION DE REQUERIMIENTOS ..............................................................66
REQUERIMIENTOS DURADEROS Y VOLTILES ............................................................................66
CLASIFICACION DE LOS REQUERIMIENTOS VOLATILES ...............................................................67
GESTIN DE CAMBIOS DE LOS REQUERIMIENTOS. ....................................................................68
Conclusin ..................................................................................................................................70
Bibliografa .................................................................................................................................71

Tema: Validacin De requisitos

La validacin de requerimientos trata de mostrar que estos realmente definen el
sistema que el cliente desea. Coincide principalmente con el anlisis ya que este
implica encontrar problemas con los requerimientos. La validacin de
requerimientos es importante debido a errores en el documento de
requerimientos pueden conducir a importantes costes al repetir el trabajo cuando
son descubiertos durante el desarrollo o despus de que el sistema est en uso.
La razn de esto es que un cambio en los requerimientos normalmente significa
que el diseo y la implementacin del sistema tambin deben cambiar y que este
debe probarse nuevamente.
Durante el proceso de validacin de requerimientos, se deben llevar acabo
verificaciones sobre requerimientos en el documento de requerimientos. Estas
verificaciones comprenden:

Verificaciones de validez:
Un usuario puede pensar que se necesitan un sistema para llevar acabo ciertas
funciones. Sin embargo el razonamiento y el anlisis pueden identificar que se
requieren funciones adicionales o diferentes.

Verificaciones de consistencia:
Los requerimientos en el documento no deben contradecirse. Esto es, no debe
haber restricciones propuestas por el usuario del sistema.

Verificaciones de completitud:
El documento de requerimientos debe incluir requerimientos que definan todas
las funciones y restricciones propuestas por el usuario del sistema.

Verificacin del realismo:

Utilizando el conocimiento de la tecnologa existente, los requerimientos
deben verificarse para asegurar que se pueden implementar. Estas
verificaciones tambin deben tener en cuenta el presupuesto y la confeccin
de agendas para el desarrollo del sistema

 Verificabilidad:
Para reducir la posibilidad de discusiones entre el cliente y el contratista, los
requerimientos del sistema siempre deben redactarse de tal forma que seas
verificables. Esto significa que debe poder escribir un conjunto de pruebas que
demuestren que el sistema a entregar cumple cada uno de los requerimientos
especificados.

REVISIONES DE REQUERIMIENTOS
Una revisin de requerimiento es un proceso manual que involucra a personas
tanto de la organizacin del cliente como de la contratista. Ellos verifican el
documento de requerimientos en cuanto a anomalas y omisiones. El proceso
de revisin se puede gestionar de la misma forma que las inspecciones de
programas.
Las

revisiones de requerimientos pueden ser informales

o formales. Las

informales sencillamente implican que los contratistas deben tratar los

requerimientos con tantos stakeholders d del sistema como sea posible.

GESTION DE REQUERIMIENTOS
La gestin de requerimientos es el proceso de comprender y controlar los
cambios en los requerimientos del sistema. Es necesario mantenerse al tanto
de los requerimientos particulares y mantener vnculos entre los requerimientos
dependientes de forma que se pueda evaluar el impacto de los cambios en los
requerimientos.

PLANIFICACION DE LA GESTION DE REQUERIMIENTOS

La planificacin es una primera etapa esencial del proceso de la gestin de
requerimientos.

REQUERIMIENTOS DURADEROS Y VOLTILES

Requerimientos duraderos:

Son requerimientos relativamente estables que se derivan de la actividad

principalmente de la organizacin y que estn relacionados directamente
con el dominio del sistema.

Requerimientos voltiles:

Son requerimientos que probablemente cambian durante el proceso de

desarrollo del sistema o despus de que se haya puesto en
funcionamiento

CLASIFICACION DE LOS REQUERIMIENTOS VOLATILES

TIPO DE REQUERIMIENTOS
DESCRIPCION
REQUERIMIENTOS CAMBIANTES Requerimientos que cambian debido a
los cambios en el entorno en el que
opera la organizacin.
REQUERIMIENTOS EMERGENTES Requerimientos que emergen al
incrementarse la comprensin del
cliente en el desarrollo del sistema.
REQUERIMIENTOS
CONSECUENTES

Requerimientos que son resultado de

la
introduccin
del
sistema
informtico.

REQUERIMIENTOS
COMPATIBILIDAD

DE Requerimientos que dependen de

sistemas particulares o procesos de
negocios dentro de la organizacin.

REQUERIMIENTOS CAMBIANTES
Requerimientos que cambian debido a los cambios en el entorno en el que opera
la organizacin.

REQUERIMIENTOS EMERGENTES
Requerimientos que emergen al incrementarse la comprensin del cliente en el
desarrollo del sistema.

REQUERIMIENTOS CONSECUENTES
Requerimientos que son resultado de la introduccin del sistema informtico.

REQUERIMIENTOS DE COMPATIBILIDAD
Requerimientos que dependen de sistemas particulares o procesos de negocios
dentro de la organizacin.

 LA IDENTIFICACION DE REQUERIMIENTOS
Cada requerimiento se debe identificar de forma nica de tal forma que puedan
ser remitidos por otros requerimientos de manera que pueda utilizarse en las
evaluaciones de rastreo.

UN PROCESO DE GESTION DEL CAMBIO

Este es el conjunto de actividades que evalan el impacto y coste de los cambios.

POLITICAS DE RASTREO
Estas polticas definen las relaciones entre los requerimientos, y entre estos y el
diseo del sistema que se debe registrar y la manera en que estos registros se
deben mantener.

AYUDA DE HERRAMIENTAS CASE

La gestin de requerimientos comprende el procesamiento de grandes
cantidades de informacin sobre los requerimientos.

GESTIN DE CAMBIOS DE LOS REQUERIMIENTOS.

Se debe aplicar a todos los cambios propuestos en los requerimientos. La

ventaja de utilizar un proceso formal para gestionar el cambio es que todos los
cambios propuestos son tratados de una forma consistente y que los cambios en
el documento de requerimientos se hacen de forma controlada.
Existen tres etapas principales en un proceso de gestin del cambio.

Anlisis del problema y especificacin del problema.

El proceso empieza con la identificacin de un problema en los requerimientos o
una propuesta especfica al cambio donde esta etapa se encarga de verificar que
esta sea vlida.

Anlisis del cambio y clculo de costes.

El efecto de un cambio propuesto se valora utilizando la informacin de rastreo
y el conocimiento general de los requerimientos del sistema. Una vez que este
anlisis se toma la decisin sobre si se contina con el cambio de
requerimientos.

Implementacin del cambio.

Se modifica el documento de requerimientos y, en su caso, el diseo e
implementacin del sistema. Debe organizar el documento de requerimiento de
modo que pueda hacer cambios en l sin tener que hacer grandes
reorganizaciones.

El usuario tiene que establecer la prioridad del cambio y, si es de alta prioridad.

Existe siempre la tentacin de hacer ese cambio al sistema y entonces modificar
de forma retrospectiva el documento de requerimientos. Esto conduce casi
inevitablemente a que la especificacin de requerimientos y la implementacin
del sistema se desfasen.

Conclusin
En la actualidad, son muchos los procesos de desarrollo de software
que existen.
La razn principal para escoger este tema se fundament en la gran
cantidad de proyectos de software que no llegan a cumplir sus
objetivos.
Ya que algunas veces no hacemos una validacin repetida de un
proceso aprobado (o una parte de ste) para asegurar el
cumplimiento continuo con los
Requerimientos establecidos. La razn de esto es que un cambio en
los requerimientos normalmente significa que el diseo y la
implementacin del sistema tambin deben cambiar y que este debe
probarse nuevamente.
Las revisiones de requerimientos pueden ser informales o formales.
Las informales sencillamente implican que los contratistas deben
tratar los requerimientos con tantos stakeholders d del sistema como
sea posible.

Bibliografa

ingeniera de Requisitos en Aplicaciones para la Web Un estudio

comparativo. Departamento de Lenguajes y Sistemas Informticos

Escuela Tcnica Superior de Ingeniera Informtica Universidad de Sevilla

Validacin de Requisitos. Mster de Ingeniera del Software-A distancia.

Mdulo II- Requisitos de Sistemas Software

En esta unidad nos dimos a la tarea de analizar y poder as comprender el tema

que es Administracin de Requerimientos el cual se observ y se logr aprender
lo que es el estudio de factibilidad. La investigacin de factibilidad en un proyecto
que consiste en descubrir cules son los objetivos de la organizacin, luego
determinar si el proyecto es til para que la empresa logre sus objetivos. Como
tambin se analizaron tres aspectos del estudio de factibilidad los cuales son
Factibilidad Operativa la cual se refiere a todos aquellos recursos donde
intervienen algn tipo de actividad, depende de los recursos humanos que
participan durante la operacin del proyecto; la Factibilidad Tcnica se refiere a
los recursos necesarios como herramientas, conocimientos, habilidades,
experiencia, etc., que son necesarios para efectuar las actividades o procesos
que requiere el proyecto y por ltimo la Factibilidad Econmica la cual se refiere
a los recursos econmicos y financieros necesarios para desarrollar o llevar a
cabo las actividades o procesos y/o para obtener los recursos bsicos que deben
considerarse son el costo del tiempo, el costo de la realizacin y el costo de
adquirir nuevos recursos.

De igual manera, se analizaron los temas de obtencin y anlisis de

requerimientos en la cual es una etapa del proceso de ingeniera de
requerimientos. Ya que en esta actividad, los ingenieros de software trabajan con
los clientes y los usuarios finales del sistema para determinar el dominio de la
aplicacin, que servicios debe proporcionar el sistema, el rendimiento requerido
del sistema, las restricciones hardware, etc. El siguiente paso es el de
Especificacin de requerimientos y por ltimo el de Validacin de requerimientos
en el cual trata de mostrar que estas realmente definen el sistema que el cliente
desea.

Universidad Tecnolgica de Campeche

T.S.U. Tecnologas de la Informacin y Comunicacin.
rea: Sistemas Informticos.
Asignatura:
Ingeniera de Software I

Nombre del docente:

Jess Humberto Murillo Flores.

Unidad III. Anlisis y modelado del desarrollo del software

con UML.
Alumno:
Heberet Martnez Snchez.
Grado: 4

Grupo: B

Periodo: Septiembre-Diciembre 2015

San Antonio Crdenas, Carmen, Campeche; Octubre de 2015.

Universidad Tecnolgica de Campeche

T.S.U. Tecnologas de la Informacin y Comunicacin.
rea: Sistemas Informticos.

Asignatura:
Ingeniera de Software

Nombre del docente:

Jess Humberto Murillo Flores
Unidad III:
Anlisis y modelado de desarrollo de software con UML
Actividad:
Practica

Presentado por:
Cindy del C. Snchez Salvador
Zurisadai May Daz
Maritza Gernimo Snchez
Heberet Martnez Snchez

Grado: 4

Grupo: B

Periodo: Septiembre - diciembre 2015

San Antonio Crdenas, Carmen, Campeche; diciembre de 2015

Introduccin
En esta unidad nos dimos a la tarea de aprender el lenguaje de modelado
unificado mejor conocido como UML, esto con la finalidad de comprender
a fondo y concisamente la etapa de planificacin y anlisis para el
desarrollo de un proyecto, que nos ha permitido, analizar, razonar,
ubicarnos y graficar el proceso que tendr nuestro proyecto a la hora de
ser implementado. No solo en la teora, sino, tambin en la prctica, es
ms que sabido que necesitamos los diagramas UML para plantearnos
que meta tenemos trazada, cual ser nuestro prototipo a seguir y que es
en s, lo que queremos o necesitamos para satisfacer alguna o algunas
prioridades a la hora de programar o desarrollar un software en cualquier
lenguaje de programacin que deseemos trabajar

Diagrama de caso de uso

Diagrama de clases

Diagrama de secuencia

Diagrama de estados

Conclusin

En esta prctica nos enfocamos en dar a conocer ejemplos de diagramas de

UML todo esto basndonos en el desarrollo de nuestro respectivo proyecto esto
es de suma importancia ya que este lenguaje de modelado es una notacin
grfica y permite especificar, construir, visualizar y documentar los objetos en un
sistema programado. Sin duda alguna es muy requerida en la etapa de anlisis
de un sistema y esto dictaminara si el proyecto solventara lo pedido tanto por los
docentes en esta etapa educativa y/o tambin por los que en algn momento
fuera un cliente hablando en campo laboral.

Diapositivas:

Universidad Tecnolgica de Campeche

T.S.U. Tecnologas de la Informacin y Comunicacin.
rea: Sistemas Informticos.
Asignatura:
Ingeniera de Software I

Nombre del docente:

Jess Humberto Murillo Flores.

Unidad III. Anlisis y modelado del desarrollo del software

con UML.
Alumnos:
Maritza Gernimo Snchez.
Heberet Martnez Snchez.
Zurisadai May Daz.
Cindy del Carmen Snchez Salvador.

Grado: 4

Grupo: B

Periodo: Septiembre-Diciembre 2015

San Antonio Crdenas, Carmen, Campeche; Octubre de 2015.

Introduccin
Un diagrama de clases sirve para visualizar las relaciones entre las clases que
involucran el sistema, las cuales pueden ser asociativas, de herencia, de usos y
de contenido.
Un diagrama de clases est compuesto por los siguientes elementos
Clase: atributos, mtodos y visibilidad
Relaciones: herencia, composicin, agregacin, asociacin y uso.
Interfaces: mtodos con funcionalidades generales que implementaran varias
clases del modelo.
Paquetes: subconjunto del modelo que va a contener clases. Objetos y
relaciones.

ndice
Introduccin...............................................................................................................................2
Diagrama de clases.......................................................................................................................4
Clase.............................................................................................................................................4
Atributos.......................................................................................................................................5
Operaciones.................................................................................................................................5
Plantillas.......................................................................................................................................6
Asociaciones de clases..................................................................................................................6
Generalizacin..............................................................................................................................6
Asociaciones.................................................................................................................................7
Acumulacin.................................................................................................................................8
Composicin.................................................................................................................................8
Interfaces......................................................................................................................................9
Tipo de datos................................................................................................................................9
Enumeraciones.............................................................................................................................9
Paquetes.......................................................................................................................................9
Conclusin..................................................................................................................................10
Bibliografa..................................................................................................................................11

Diagrama de clases
Los diagramas de clases muestran las diferentes clases que componen un
sistema y cmo se relacionan unas con otras. Se dice que los diagramas de
clases son diagramas estticos porque muestran las clases, junto con sus
mtodos y atributos, as como las relaciones estticas entre ellas: qu clases
conocen a qu otras clases o qu clases son parte de otras clases, pero no
muestran los mtodos mediante los que se invocan entre ellas.

Clase
Una clase define los atributos y los mtodos de una serie de objetos. Todos los
objetos de esta clase (instancias de esa clase) tienen el mismo comportamiento
y el mismo conjunto de atributos (cada objetos tiene el suyo propio). En
ocasiones se utiliza el trmino tipo en lugar de clase, pero recuerde que no
son lo mismo, y que el trmino tipo tiene un significado ms general.
En , las clases estn representadas por rectngulos, con el nombre de la clase,
y tambin pueden mostrar atributos y operaciones de la clase en otros dos
compartimentos dentro del rectngulo.

Mtodos:
Los mtodos u operaciones de una clase son la forma en como esta interacta
con su entorno, estos pueden tener las siguientes caractersticas:
Public: indica que el mtodo ser visible tanto dentro como fuera de la clase.
Prvate: explica que el mtodo solo ser accesible desde dentro de la clase.
Protected: indica que el mtodo no ser accesible desde fuera de la clase pero
si podr ser accesado por mtodos de la clase.

Atributos
En UML, los atributos se muestran al menos con su nombre, y tambin pueden
mostrar su tipo, valor inicial y otras propiedades. Los atributos tambin pueden
ser mostrados visualmente:
+ Indica atributos pblicos
# Indica atributos protegidos
- Indica atributos privados

Operaciones
Las operaciones (mtodos) tambin se muestran al menos con su nombre, y
pueden mostrar sus parmetros y valores de retorno. Las operaciones, al igual
que los atributos, se pueden mostrar visualmente:
+ Indica operaciones pblicas
# Indica operaciones protegidas
- Indica operaciones privadas

Plantillas
Las clases pueden tener plantillas, un valor usado para una clase no especificada
o un tipo. El tipo de plantilla se especifica cuando se inicia una clase (es decir
cuando se crea un objeto). Las plantillas existen en C++ y se introducirn en
Java 1.5 con el nombre de Genricos.

Asociaciones de clases
Las clases se puede relaciones (estar asociadas) con otras de diferentes
maneras:

Generalizacin
La herencia es uno de los conceptos fundamentales de la programacin
orientada a objetos, en la que una clase recoge todos los atributos y
operaciones de la clase de la que es heredera, y puede alterar/modificar algunos
de ellos, as como aadir ms atributos y operaciones propias.
En UML, una asociacin de generalizacin entre dos clases, coloca a estas en
una jerarqua que representa el concepto de herencia de una clase derivada de

la clase base. En UML, las generalizaciones se representan por medio de una lnea
que conecta las dos clases, con una flecha en el lado de la clase base.

Asociaciones

Una asociacin representa una relacin entre clases, y aporta la semntica

comn y la estructura de muchos tipos de conexiones entre objetos.
Las asociaciones son los mecanismos que permite a los objetos comunicarse
entre s. Describe la conexin entre diferentes clases (la conexin entre los
objetos reales se denomina conexin de objetos o enlace).
Las asociaciones pueden tener un papel que especifica el propsito de la
asociacin y pueden ser unidireccionales o bidireccionales (indicando si los dos
objetos participantes en la relacin pueden intercambiar mensajes entre s, o es
nicamente uno de ellos el que recibe informacin del otro). Cada extremo de la
asociacin tambin tiene un valor de multiplicidad, que indica cuntos objetos de
ese lado de la asociacin estn relacionados con un objeto del extremo contrario.
En UML, las asociaciones se representan por medio de lneas que conectan las
clases participantes en la relacin, y tambin pueden mostrar el papel y la
multiplicidad de cada uno de los participantes. La multiplicidad se muestra como
un rango [mn...Mx.] De valores no negativos, con un asterisco (*)
representando el infinito en el lado mximo.

Acumulacin
Las acumulaciones son tipos especiales de asociaciones en las que las dos clases
participantes no tienen un estado igual, pero constituyen una relacin completa.
Una acumulacin describe cmo se compone la clase que asume el rol completo de
otras clases que se encargan de las partes. En las acumulaciones, la clase que
acta como completa, tiene una multiplicidad de uno. En UML, las acumulaciones
estn representadas por una asociacin que muestra un rombo en uno de los lados
de la clase completa.

Composicin
Las composiciones son asociaciones que representan acumulaciones muy
fuertes. Esto significa que las composiciones tambin forman relaciones
completas, pero dichas relaciones son tan fuertes que las partes no pueden
existir por s mismas. nicamente existen como parte del conjunto, y si este es
destruido las partes tambin lo son.
En UML, las composiciones estn representadas por un rombo slido al lado del
conjunto.

Interfaces
Las interfaces son clases abstractas, lo que significa que no es posible crear
instancias directamente a partir de ellas. Pueden contener operaciones, pero no
atributos. Las clases pueden heredar de las interfaces (a travs de una
asociacin de realizacin) y de estos diagramas s es posible crear instancias.

Tipo de datos
Los tipos de datos son primitivas construidas normalmente en algunos lenguajes
de programacin. Algunos ejemplos comunes son los enteros y los booleanos.
No pueden tener relacin con clases, pero las clases s pueden relacionarse con
ellos.

Enumeraciones
Las enumeraciones son simples listas de valores. Un ejemplo tpico de esto sera
una enumeracin de los das de la semana. Las opciones de una enumeracin se
llaman literales de enumeracin. Al igual que los tipos de datos, no pueden
relacionarse con las clases, pero las clases s pueden hacerlo con ellos.

Paquetes
Los paquetes, en lenguajes de programacin, representan un espacio de
nombres en un diagrama se emplean para representar partes del sistema que
contienen ms de una clase, incluso cientos de ellas.

Conclusin

Los diagramas de clases muestran las diferentes clases que

componen un sistema y cmo se relacionan unas con otras. Se dice
que los diagramas de clases son diagramas estticos porque
muestran las clases, junto con sus mtodos y atributos, as como las
relaciones estticas entre ellas: qu clases conocen a qu otras
clases o qu clases son parte de otras clases, pero no muestran
los mtodos mediante los que se invocan entre ellas.
Una clase define los atributos y los mtodos de una serie de objetos.
Todos los objetos de esta clase (instancias de esa clase) tienen el
mismo comportamiento y el mismo conjunto de atributos (cada
objetos tiene el suyo propio). En ocasiones se utiliza el trmino tipo
en lugar de clase, pero recuerde que no son lo mismo, y que el
trmino tipo tiene un significado ms general.

Bibliografa
Conceptos Bsicos sobre el UML
Hermenegildo Romero
2009 DATABASE TEAM
http://docs.kde.org/

En esta unidad que es el tercer tema ya que trato sobre lo que es el Lenguaje
Unificado de Software (UML) el cual est basado en una notacin grafica la cual
permite especificar, construir, visualizar y documentar los objetos de un sistema
programado. Como tambin tiene otra descripcin el cual es la siguiente el UML
modela sistema mediante el uso de objetos que forman parte del as como, las
relaciones estticas o dinmicas que existen entre ellos.
As mismo, podemos decir que se estudi los distintos diagramas que conforma
el UML como son el Diagrama de Casos de Uso el cual este muestra las distintas
operaciones que se esperan de una aplicacin o sistema y como se relaciona
con su entorno. Ya que tambin es una herramienta esencial para la captura de
requerimientos y para la planificacin y control de un proyecto interactivo. El
diagrama de casos de uso tiene varios elementos los cuales podemos mencionar
como son los casos de uso, actor y tambin se encuentran 3 tipos de relaciones.
El Diagrama de Clases es otro diagrama que viene incluido en el UML ya que
muestra el conjunto de clases y objetos importantes que forman parte de un
sistema, junto con las relaciones existentes entre clases y objetos.
De igual manera, el Diagrama de secuencia este muestra la interaccin de un
conjunto de objetos de una aplicacin a travs del tiempo. El diagrama de
colaboracin es una forma de representar interaccin entre el objeto, es decir,
las relaciones entre ellos y la secuencia de los mensajes de las iteraciones que
estn indicadas por nmero. Y por ltimo, el Diagrama de Estado ya que este
muestra el conjunto de estado por los cuales pasa un objeto durante su vida en
una aplicacin junto con los cambios que permiten pasar de un estado a otro.

Cabe mencionar que en esta asignatura que es la de Ingeniera de Software I

nos dimos a la tarea de aprender como primer punto lo que son las metodologas
de desarrollo de software ya que esta es un marco de trabajo para estructurar,
planificar y controlar el proceso de desarrollo en sistemas de informacin.
Tambin analizamos la clasificacin de las metodologas ya que en este caso se
mencionaron el modelo de cascada en el cual el desarrollo se ve como una serie
de escalones descendientes a travs de las distintas fases, dichas fases son la
de Anlisis, Diseo, Desarrollo, Pruebas, Integracin y Mantenimiento. De igual
manera, se habl sobre la metodologa de prototipos ya que se conoce as a las
actividades de creacin de prototipos durante el desarrollo de software, los
prototipos son versiones incompletas del producto que va a ser desarrollado. Y
como tambin estn los modelos de espiral y el RAD; como de igual manera se
vieron las ventajas y desventajas de cada metodologa de desarrollo de software.
En la segunda unidad se habl sobre el tema de Administracin de
Requerimientos en el cual la investigacin de factibilidad en un proyecto que
consiste en descubrir cules son los objetivos de la organizacin, luego
determinar si el proyecto es til para que la empresa logre sus objetivos. Cabe
mencionar que nos dimos a conocer el proceso de factibilidad en sus tres puntos
de vista la cuales son Tcnica ya que este se refiere a los recursos necesario
como herramientas, conocimientos, habilidades, experiencia, etc., que son
necesarios para efectuar las actividades o procesos que requiere el proyecto. La
factibilidad Operativa se refiere a todos aquellos recursos donde intervienen
algn tipo de actividad y la factibilidad Econmica. Tambin se estudi la
obtencin y anlisis de requerimientos, Especificacin de requerimientos y
Validacin de requerimientos.
Para concluir mencionaremos la unidad 3 en la cual analizamos los distintos
Diagramas de UML la cuales son Diagrama de Casos de uso, Diagramas de
Clases, Diagramas de Secuencia, Diagrama de Colaboracin y Diagrama de
Estado.