TECNOLÓGICO DE ESTUDIOS SUPERIORES DE CHALCOINGENIERÍA INFORMÁTICA

PRACTICA DE ANALISIS Y MODELADO DE SISTEMAS DEINFORMACION 1, 2 y 3

Materia: Análisis y Modelado de Sistemas de InformaciónDocente: Sandra Hernández SúarezAlumno: Iván García Ceballos

Chalco, Estado de México, a 16 de Octubre de 2014.

METODOS DE DESARROLLO DE SOFTWARE ORIENTADO A OBJETOS

CONCEPTOS

1. La Ingeniería del Software y la Orientación a Objetos son dos

áreas que su intersección producen técnicas y metodologías que

pretenden facilitar la construcción de software.

2. La programación Orientada a Objetos se basa en tres

principios básicos: todos son objetos,

Encapsulamiento/ocultación y herencia / polimorfismo.

El primer principio indica la unidad básica de trabajo

El segundo permite englobar en un mismo concepto a los

datos y a las operaciones

El tercero permite agrupar y tratar de igual forma a

objetos similares

3. El desarrollo orientado a objetos está jugando un papel cada

vez más importante en el diseño e implementación de sistemas

software, hasta el punto de que su influencia está siendo

comparada a la de la programación estructurada de los años 70.

Se considera como pionero de la aproximación Orientada a

Objetos el lenguaje Smalltalk. Lo que en sus inicios fue tan

solo un lenguaje de programación dio lugar posteriormente a

toda una corriente en el mundo del desarrollo del software, a

cuyo amparo se han desarrollado metodologías de diseño y

lenguajes de programación.

4. El desarrollo de software orientado a objetos, es una

aproximación diferente a las tradicionales metodologías

estructuradas. Estas se basan en la descomposición de un

sistema en módulos atendiendo a consideraciones

procedimentales y/o de datos.

5. • Facilita la transición entre distintas fases

• Favorece el desarrollo iterativo del sistema

• Disipa la barrera entre el “qué” y el “cómo” Sin

embargo, existen problemas

MODELO DE REQUISITOS

• Permite delimitar y darle claridad al problema con susimplicaciones, con el acompañamiento del usuario pero con laperspectiva del desarrollador.

MODELO DE ANALISIS

• El objetivo del modelo de análisis es comprender y generar unaarquitectura de objetos para el sistema en base a loespecificado en el modelo de requisitos.

• No se considera el ambiente de implementación todavía, enotras palabras el análisis pretende modelar el sistema bajocondiciones ideales.

MODELO DE DISEÑO

Prototipos de Diseño

• Se desarrolla para explorar y comprender la arquitecturaparticular del sistema, sirve como base para la evaluación derendimiento y espacio y para pruebas de redundancia einconsistencias en el diseño. Identifica cuellos de botella enel sistema y donde se quiere revisar con más detalle el productofinal.

MODEL

O DE IMPLEMENTACION

• En esta etapa lo más importante es definir el código fuente de laaplicación.

• El modelo de implementación toma el resultado del modelo dediseño para generar el código final.

• Con un buen diseño, la tarea de implementación es mucho másfluida, y el implementador se ocupa solo de resolver problemas deimplementación.

• Ejemplo: si se necesita una funcionalidad que no fue diseñada

MODELO DE PRUEBAS

Uno de los objetivos de la fase de pruebas del sistema es

verificar que el comportamiento externo del sistema software

satisface los requisitos establecidos por los clientes y futuros

usuarios del mismo. A medida que aumenta la complejidad de los

sistemas software y aumenta la demanda de calidad, se hacen

necesarios procesos y métodos que permitan obtener buenos

conjuntos de pruebas del sistema. Este trabajo describe los

modelos necesarios para generar de manera sistemática un conjunto

de pruebas que permitan verificar la implementación de los

requisitos funcionales de un sistema software.

• Encargado de revisar la calidad del sistema desarrollado

• Debe ser planificado y tenido en cuenta durante toda la etapadel desarrollo

MODELO COMPARATIVAREQUISITOS Describir las necesidades de los usuarios y

las partes interesadas con mucha menosambigüedad que con el lenguaje natural

ANALISIS El objetivo del modelo de análisis escomprender y generar una arquitectura deobjetos para el sistema

DISEÑO Se desarrolla para explorar y comprender laarquitectura particular del sistema

IMPLEMENTACION En esta etapa lo más importante es definirel código fuente de la aplicación.

PRUEBAS Debe ser planificado y tenido en cuentadurante toda la etapa del desarrollo

TENDENCIAS DE UML Y RUP

CONCEPTOS

1. El Proceso Unificado Racional, Rational Unified Process en inglés,y sus siglas RUP, es un proceso de desarrollo de software y juntocon el Lenguaje Unificado de Modelado UML, constituye lametodología estándar más utilizada para el análisis,implementación y documentación de sistemas orientados a objetos.

2. El RUP no es un sistema con pasos firmemente establecidos, sinoque trata de un conjunto de metodologías adaptables al contexto ynecesidades de cada organización, donde el software es organizadocomo una colección de unidades atómicas llamados objetos,constituidos por datos y funciones, que interactúan entre sí.

3. RUP es explícito en la definición de software y su trazabilidad,es decir, contempla en relación causal de los programas creadosdesde los requerimientos hasta la implementación y pruebas.

4. RUP identifica claramente a los profesionales (actores)involucrados en el desarrollo del software y sus responsabilidadesen cada una de las actividades.

5. RUP es un proceso para el desarrollo de un proyecto de un softwareque define claramente quien, cómo, cuándo y qué debe hacerse en elproyecto.

6. RUP para el desarrollo de software moderno que junto con UML tratade mejorar el desarrollo de software no solo con una serie depasos establecidos si no combinando varios modelos, estodependiendo de las necesidades de la empresa que lo solicite.

CONCEPTOS

1. Es un lenguaje usado para especificar, visualizar y documentar losdiferentes aspectos relativos a un sistema de software bajodesarrollo, así como para como para modelado de negocios yalmacenamiento de datos.

2. UML es un lenguaje para hacer modelos y es independiente de losmétodos de análisis y diseño. Existen diferencias importantes entreun método y un lenguaje de modelado. Un método es una maneraexplícita de estructurar el pensamiento y las acciones de cadaindividuo.

3. UML define una notación y una meta modelo, donde la Notación es elmaterial gráfico que se ve en los modelos, es la sintaxis dellenguaje de modelado. Por ejemplo: es la denominación de un diagramade clases donde se define su representación, conceptos y temas como:clases, asociación y modelos.

4. UML son las siglas para Unified Modeling Language, que en castellanoquiere decir: Lenguaje de Modelado Unificado.

5. Es un lenguaje de modelado visual de propósito general orientado aobjetos. Agrupa notaciones y conceptos provenientes de distintos tiposde métodos orientados a objetos.

6. Una abstracción es una simplificación, que incluye sólo aquellosdetalles relevantes para algún determinado propósito.

EJEMPLOS

MODELO DE ACTIVIDADES

MODELO ENTIDAD RELACION

MODELO DE COLABORACIÓN

MODELO DE COMPONENTES

MODELO DE ESTADOS

MODELO DE CASO DE USO

TABLA COMPARATIVA

MODELO DE CASO DE

USO

MODELO DE

COMPONENTES

MODEL DE RELACION

DEFINICION

Los diagramas

de casos de

uso documentan

el

comportamiento

de un sistema

desde el punto

de vista del

usuario.

Su ventaja

principal es

la facilidad

para

interpretarlos

, lo que hace

que sean

especialmente

útiles en la

comunicación

con el

cliente.

Es un paquete

de software,

un servicio

web, o un

módulo que

encapsula un

conjunto de

funciones

relacionadas

(o de datos).

El cuál es elmodelo másutilizado enla actualidadparaimplementarbases de datosyaplanificadas.

TENDENCIAS

1. Gran cantidad de aplicaciones software moderno se han desarrolladobasadas en principios orientados a objetos (clases, atributos,métodos, herencia). Una de las ventajas de la orientación aobjetos es que se presta a la representación notaciones de susprincipios.

2. Las herramientas CASE ofrecen grandes ventajas a losdesarrolladores de sistemas software de gran tamaño. Mientras unaespiral de requisitos del sistema sigue llevando la complejidaddel sistema a nuevos niveles, las herramientas CASE permitenabstraernos del código fuente, a un nivel donde la arquitectura yel diseño son más aparentes y fáciles de entender y modificar.

3. RUP divide el proceso en cuatro fases, dentro de las cuales serealizan varias iteraciones en número variable según el proyecto yen las que se hace un mayor o menor hincapié en las distintasactividades.

4. El proceso de ciclo de vida de RUP se divide en cuatro fases bienconocidas llamadas Incepción, Elaboración, Construcción yTransición. Esas fases se dividen en iteraciones, cada una de lascuales produce una pieza de software demostrable.

5. RUP es extremadamente locuaz en muchos respectos, no proporcionalineamientos claros de implementación que puedan compararse, porejemplo, a los métodos Crystal, en los que se detalla ladocumentación requerida y los roles según diversas escalas deproyecto.

6. Existe una versión recortada de RUP, dX de Robert Martin, en lacual se han tomado en consideración experiencias de diversos MAs,reduciendo los artefactos de RUP a sus mínimos esenciales y (en ungesto heroico) usando tarjetas de fichado en lugar de UML.

REQUERIMIENTOS

Requerimientos Funcionales: Son declaraciones de los servicios que

proveerá el sistema, de la manera en que éste reaccionará a

entradas particulares. En algunos casos, los requerimientos

funcionales de los sistemas también declaran explícitamente lo que

el sistema no debe hacer. Los requerimientos funcionales de un

sistema describen la funcionalidad o los servicios que se espera

que éste provea. Estos dependen del tipo de software y del sistema

que se desarrolle y de los posibles usuarios del software. Cuando

se expresan como requerimientos del usuario, habitualmente se

describen de forma general mientras que los requerimientos

funcionales del sistema describen con detalle la función de éste,

sus entradas y salidas, excepciones, etc.

Requerimientos No Funcionales: Son restricciones de los servicios ofunciones ofrecidos por el sistema. Incluyen restricciones detiempo, sobre el proceso de desarrollo, estándares, y otros. Sonaquellos requerimientos que no se refieren directamente a lasfunciones específicas que entrega el sistema, sino a laspropiedades emergentes de éste como la fiabilidad, la respuesta enel tiempo y la capacidad de almacenamiento. De forma alternativa,definen las restricciones del sistema como la capacidad de losdispositivos de entrada/salida y la representación de datos que seutiliza en la interface del sistema.

Requerimientos del Dominio: Son requerimientos que provienen deldominio de aplicación del sistema y que reflejan lascaracterísticas de ese dominio. Éstos pueden ser funcionales o nofuncionales. Se derivan del dominio del sistema más que de lasnecesidades específicas de los usuarios. Pueden ser requerimientosfuncionales nuevos, restringir los existentes o establecer cómo sedeben ejecutar cálculos particulares. Los requerimientos deldominio son importantes debido a que a menudo reflejan losfundamentos del dominio de aplicación. Si estos requerimientos nose satisfacen, es imposible hacer que el sistema trabaje de forma

satisfactoria. Ejemplo en un Sistema de Biblioteca, este deberáproveer visores para que el usuario lea documentos en el almacén dedocumentos

Atributos de calidad de Software.

Funcionalidad: Un conjunto de atributos que se relacionan con laexistencia de un conjunto de funciones y sus propiedadesespecíficas. Las funciones son aquellas que satisfacen lasnecesidades implícitas o explícitas.

Idoneidad

Exactitud

Interoperabilidad

Seguridad

Cumplimiento de normas.

Fiabilidad: Un conjunto de atributos relacionados con la capacidaddel software de mantener su nivel de prestación bajo condicionesestablecidas durante un período establecido.

Madurez

Recuperabilidad

Tolerancia a fallos

Usabilidad: Un conjunto de atributos relacionados con el esfuerzonecesario para su uso, y en la valoración individual de tal uso,por un establecido o implicado conjunto de usuarios.

Aprendizaje

Comprensión

Operatividad

Atractividad

Eficiencia: Conjunto de atributos relacionados con la relaciónentre el nivel de desempeño del software y la cantidad de recursosnecesitados bajo condiciones establecidas.

Comportamiento en el tiempo

Comportamiento de recursos

Mantenibilidad: Conjunto de atributos relacionados con la facilidadde extender, modificar o corregir errores en un sistema software.

Estabilidad

Facilidad de análisis

Facilidad de cambio

Facilidad de pruebas

Portabilidad: Conjunto de atributos relacionados con la capacidadde un sistema software para ser transferido desde una plataforma aotra.

Capacidad de instalación

Capacidad de reemplazamiento

Adaptabilidad

Co-Existencia

BIBLIOGRAFIA

METODOS DE DESARROLLO DE SOFTWARE

http://profesores.fi-b.unam.mx/carlos/aydoo/conceptos_oo.html

Fecha de Publicación: 23 de Febrero del 2009

Fecha de Consulta: 12 de Octubre del 2014

CONCEPTOS DE UML

http://alfa.facyt.uc.edu.ve/computacion/pensum/cs0347/download/

exposiciones2006-2007/presentacion%20UML.pdf

Fecha de Publicación: 23 de Febrero del 2009

Fecha de Consulta: 12 de Octubre del 2014

CONCEPTO DE UML

http://www.epidataconsulting.com/tikiwiki/tiki-read_article.php?

articleId=15

Fecha de Publicación: 07 de Febrero del 2009

Fecha de Consulta: 12 de Octubre del 2014

RUP

http://ingenieriadesoftwarerigo.blogspot.mx/2012/09/uml-y-rup.html

Fecha de Publicación: 13 de Septiembre del 2012

Fecha de Consulta: 12 de Octubre del 2014

TENDENCIAS

http://www.diatel.upm.es/malvarez/UML/Tendencias.html

Fecha de Consulta: 12 de Octubre del 2014

REQUERIMIENTOS FUNCIONALES

http://sistemas.uniandes.edu.co/~csof5101/dokuwiki/lib/exe/

fetch.php?media=principal:2013-

introducionyfundamentosderequerimientos.pdf

Fecha de Consulta: 12 de Octubre del 2014

QUE SON LOS REQUERIMIENTOS

http://www.galeon.com/zuloaga/Doc/AnalisisRequer.pdf

Fecha de Consulta: 12 de Octubre del 2014

REQUERIMIENTOS

http://www.cic.ipn.mx/sitioCIC/images/sources/cic/tesis/

A971562.pdf

Fecha de Publicación: Junio del 2003

Fecha de Consulta: 10 de Octubre del 2014