Instituto tecnolgico superior de Cintalapa

CATEDRTICO: JOS LUIS

CADENAS OCAA
MATERIA:
ANALISIS Y MODELADO DE INFORMATICA

INTEGRANTES: EQUIPO #2 GRADO: GRUPO:

BLADIMIR RAMIREZ OVANDO 5 F
REBECA ANHI PEA RIOS
JUAN SEBASTIAN PEREZ MARTINEZ
SAMUEL SANCHEZ ANGEL
ARGENIS TOLEDO JIMENEZ
 CAPITULO I INGENERIA DE SOFTWARE CON
COMPONENTES

Beneficios del Desarrollo de Software basado en Componentes. En esencia, un componente es una

pieza de cdigo pre elaborado que encapsula alguna funcionalidad expuesta a travs de interfaces
estndar (1). Los componentes son los "ingredientes de las aplicaciones", que se juntan y combinan
para llevar a cabo una tarea
(2). Es algo muy similar a lo que podemos observar en el equipo de msica que tenemos en nuestra
sala. Cada componente de aquel aparato ha sido diseado para acoplarse perfectamente con sus pares,
las conexiones son estndar y el protocolo de comunicacin est ya preestablecido. Al unirse las partes,
obtenemos msica para nuestros odos. El paradigma de ensamblar componentes y escribir cdigo para
hacer que estos componentes funcionen se conoce como Desarrollo de Software Basado en
Componentes. El uso de este paradigma posee algunas ventajas:
 1. Reutilizacin del software. Nos lleva a alcanzar un mayor nivel de reutilizacin de software.
2. Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno de los
componentes antes de probar el conjunto completo de componentes ensamblados.
3. Simplifica el mantenimiento del sistema. Cuando existe un dbil acoplamiento entre componentes,
el desarrollador es libre de actualizar y/o agregar componentes segn sea necesario, sin afectar otras
partes del sistema.
4. Mayor calidad. Dado que un componente puede ser construido y luego mejorado continuamente por
un experto u organizacin, la calidad de una aplicacin basada en componentes mejorar con el paso
del tiempo.
 Metrpolis: Analoga de la Evolucin del Software basado en Componentes. Pat Halland, uno de
los arquitectos con mayor experiencia en Microsoft, ha desarrollado recientemente una metfora
llamada Metrpolis, en la cual compara la evolucin de las tecnologas de la informacin con la forma
como las ciudades de Estados Unidos han evolucionado durante los 2 ltimos siglos. Al comprender la
evolucin de las ciudades actuales, podemos darnos una idea del futuro promisorio que tiene el
desarrollo de software basado en componentes. Como lo menciona Halland, las ciudades y las casas
de software comparten un pasado muy similar, pues ambas empezaron en ambientes que se
desarrollaron aisladamente. Este desarrollo independiente conllev a diferencias de cultura con
respecto a la forma como se hacan las cosas. A mediados del siglo XIX, las vas de ferrocarril
conectaron la mayor parte de las ciudades en los Estados Unidos. Esto permiti que las personas y
distintos artculos empezaran a trasladarse de una forma que no era posible anteriormente. Se inici
entonces una carrera por asegurar que los artculos trabajen entre s y cumplan estndares de
compatibilidad. Estos cambios en expectativas y capacidades alimentaron la explosin del comercio, la
fabricacin y llevaron a la urbanizacin de la vida, tal y como la conocemos hoy. Por muchos aos, las
casas de software han desarrollado aisladamente, con aplicaciones creadas independientemente y sin
mayor necesidad de interaccin entre ellas. Dado que estas aplicaciones no estaban conectadas, no
haba mayores consecuencias
para aquello. Pero recientemente se ha vuelto muy prctico el interconectar tanto las aplicaciones dentro
de una casa de software, as como entre mltiples casas de software alrededor del mundo. Ahora la
gente ya puede navegar y visitar aplicaciones muy distantes. Cantidades cada vez ms grandes de
informacin son fcilmente transmitidas entre aplicaciones. Pero lo que an es difcil es hacer que estos
datos trabajen entre distintas aplicaciones. Para entender entonces lo que est ocurriendo en este
momento con el ambiente IT hay que explorar 6 facetas de esta analoga: Ciudades - Casas de Software
Las ciudades evolucionaron gradualmente como lugares para hacer comercio y manufactura. En estas
ciudades existan edificios con poca o ninguna conexin entre ellos. Las ciudades tenan un contacto
muy limitado con sus ciudades aledaas y desarrollaron su propia cultura, estilo y forma de hacer cosas
(Ver Figura 1). De la misma forma, las casas de software evolucionaron gradualmente mientras nuevas
aplicaciones fueron construidas y luego extendidas. Cada aplicacin separada e independiente de sus
similares en la misma casa de software. Cada casa de software tena su propia cultura, estilo y forma de
hacer las cosas.
 CAPITULO II CONCEPTO DE OBJETOS
La programacin orientada a objetos consiste en ordenar datos en conjuntos modulares de elementos
de informacin del mundo real (denominado un dominio). Estos elementos de datos se llaman objetos.
Estos datos se agrupan de acuerdo a las caractersticas principales del mundo real de estos elementos
(tamao, color, etc.). El enfoque de objetos es una idea que se ha probado con creces. Simula fue el
primer lenguaje de programacin en implementar el concepto de clases en 1967. En 1976, Smalltalk
implement los conceptos de encapsulacin, agrupacin y herencia (los conceptos principales de la
programacin orientada a objetos). Por otra parte, se han implementado varios lenguajes de
programacin orientada a objetos a escala global (Eiffel, Objetive C, Loops, etc.).
La dificultad que presenta este enfoque es la creacin de una representacin abstracta, en forma de
objetos, de entidades que realmente existen (perro, auto, lmpara elctrica...) o que existen
virtualmente (seguridad social, clima...)
Un objeto se caracteriza por varios conceptos:
Atributos: estos son los datos que caracterizan al objeto. Son variables que almacenan datos
relacionados al estado de un objeto.
 Mtodos (usualmente llamados funciones de miembro): Los mtodos de un objeto caracterizan su
comportamiento, es decir, son todas las acciones (denominadas operaciones) que el objeto puede
realizar
. por s mismo. Estas operaciones hacen posible que el objeto responda a las solicitudes
externas (o que acte sobre otros objetos). Adems, las operaciones estn estrechamente ligadas a los
atributos, ya que sus acciones pueden depender de, o modificar, los valores de un atributo.

Identidad: El objeto tiene una identidad, que lo distingue de otros objetos, sin considerar su estado.
Por lo general, esta identidad se crea mediante un identificador que deriva naturalmente de un
problema (por ejemplo: un producto puede estar representado por un cdigo, un automvil, por un
nmero de modelo, etc.).
 CAPITULO III ESTUDIO DE UN CASO INTRODUCTORIO
Casos de uso.
Prstamo de un libro: la persona que quiere llevarse un libro lo presta. El sistema lo comprueba que es
miembro de la biblioteca y si an no ha llegado el mximo de nmeros de libros permitidos. Cada caso
de uso deber de ser documentado, generalmente en tercera persona y voz activa (el sistema y lo
comprueba).
Diagramas de caso de uso.
 Clases.
Si se ha descrito los requisitos y casos de uso posible determinar las clases mediante bsquedas de
nombres.
 Relaciones.
Analizando las dependencias entre las clases y posibles interacciones se pueden determinar las
relaciones. Una copia lo es de un libro Un miembro puede devolver o tomar un libro Un miembro
del personal puede devolver o tomar un libro Un miembro del personal puede devolver o tomar una
revista.

 Diagramas interaccin.
En aquellos casos donde un caso de uso puede ser complicado o complejo, puede ser conveniente
representarlo mediante diagramas de interaccin.
 Diagramas de estados.
Algunos de los objetos pasarn por varios estados distintos. Es interesante reflejar estos cambios a
travs de diagramas de estados.
 CAPITULO IV PROCESO DE DESARROLLO.
Paradigmas orientados a objetos. El paradigma orientado a objetos (OO) define los programas en
trminos de comunidades de objetos. Los objetos con caractersticas comunes se agrupan en clases
(un concepto similar al de tipo abstracto de dato (TAD)). Los objetos son entidades que combinan un
estado (es decir, datos) y un comportamiento (esto es, procedimientos o mtodos). Estos objetos se
comunican entre ellos para realizar tareas. Es en este modo de ver un programa donde este paradigma
difiere del paradigma imperativo o estructurado, en los que los datos y los mtodos estn separados y
sin relacin. El paradigma OO surge para solventar los problemas que planteaban otros paradigmas,
como el imperativo, con el objeto de elaborar programas y mdulos ms fciles de escribir, mantener y
reutilizar. Entre los lenguajes que soportan el paradigma OO estn Smalltalk, C++, Delphi (Object
Pascal), Java y C#.
 El lenguaje unificado de construccin de los modelos UML.
En todas las disciplinas de la Ingeniera se hace evidente la importancia de los modelos ya que
describen el aspecto y la conducta de "algo". Ese "algo" puede existir, estar en un estado de desarrollo
o estar, todava, en un estado de planeacin. Es en este momento cuando los diseadores del modelo
deben investigar los requerimientos del producto terminado y dichos requerimientos pueden incluir
reas tales como funcionalidad, performance y confiabilidad. Adems, a menudo, el modelo es dividido
en un nmero de vistas, cada una de las cuales describe un aspecto especfico del producto o sistema
en construccin. El modelado sirve no solamente para los grandes sistemas, aun en aplicaciones de
pequeo tamao se obtienen beneficios de modelado, sin embargo es un hecho que entre ms grande
y ms complejo es el sistema, ms importante es el papel de que juega el modelado por una simple
razn: "El hombre hace modelos de sistemas complejos porque no puede entenderlos en su totalidad".
UML es una tcnica para la especificacin sistemas en todas sus fases. Naci en 1994 cubriendo los
aspectos principales de todos los mtodos de diseo antecesores y, precisamente, los padres de UML
son Grady Booch, autor del mtodo Booch; James Rumbaugh, autor del mtodo OMT e Ivar Jacobson,
autor de los mtodos OOSE y Objetor y. La versin 1.0 de UML fue liberada en Enero de 1997 y ha
sido utilizado con xito en sistemas construidos para toda clase de industrias alrededor del mundo:
hospitales, bancos, comunicaciones, aeronutica, finanzas, etc.
 Los principales beneficios de UML son:
Mejores tiempos totales de desarrollo (de 50 % o ms). Modelar sistemas (y no slo de software)
utilizando conceptos orientados a objetos. Establecer conceptos y artefactos ejecutables.
Encaminar el desarrollo del escalamiento en sistemas complejos de misin crtica.
Crear un lenguaje de modelado utilizado tanto por humanos como por mquinas. Mejor soporte a
la planeacin y al control de proyectos. Alta reutilizacin y minimizacin de costos.
UML, Mtodo o Lenguaje de Modelado?
UML es un lenguaje para hacer modelos y es independiente de los mtodos de anlisis y diseo.
Existen diferencias importantes entre un mtodo y un lenguaje de modelado. Un mtodo es una
manera explcita de estructurar el pensamiento y las acciones de cada individuo. Adems, el mtodo le
dice al usuario qu hacer, cmo hacerlo, cundo hacerlo y por qu hacerlo; mientras que el lenguaje de
modelado carece de estas instrucciones. Los mtodos contienen modelos y esos modelos son
utilizados para describir algo y comunicar los resultados del uso del mtodo. Un modelo es expresado
en un lenguaje de modelado. Un lenguaje de modelado consiste de vistas, diagramas, elementos de
modelo los smbolos utilizados en los modelos y un conjunto de mecanismos generales o reglas
que indican cmo utilizar los elementos. Las reglas son sintcticas, semnticas y pragmticas.
 UML y su relacin con los procesos de desarrollo de software.
Un proceso de desarrollo de software es un mtodo de organizar actividades relacionadas con la
creacin, presentacin y mantenimiento de los sistemas de software. El lenguaje UML no define un
proceso oficial de desarrollo, en realidad UML combina un proceso de desarrollo para obtener un
producto final las dos razones importantes lo explica esto:
1- Aumentar la posibilidad de una aceptacin generalizada de la notacin estndar del modelado, sin la
obligacin de adoptar un proceso oficial.
2- La esencia de un proceso apropiado admite mucha variacin y depende de las habilidades del
personal, de la razn investigacin y desarrollo, de la naturaleza del problema y de las herramientas.
GRACIAS POR SU ATENCIN