Análisis y modelado de
Sistemas de Información
MCyTE. María de los Ángeles Martínez Morales
Competencia a desarrollar
Aplica técnicas y
herramientas para la
implementación del
modelo del sistema de
información.
Unidad 4. Modelo de implementación de
sistemas de información
4.1 Modelo de componentes
4.2 Modelo de despliegue
4.3 Planeación del desarrollo de sistemas de información.
12 de noviembre al 6 de diciembre
Evaluación: 7 de diciembre
Planeación de entrega de evidencias
No. Evidencia % Entrega
1 Exposición sobre el modelo de componentes y modelo de despliegue. 15% 14/Nov/2018
2 Elaboración del modelo de componentes 10% 21/Nov/2018
3 Elaboración del modelo de despliegue 10% 26/Nov/2018
4 Planeación del Sistema de Información 15% 28/Nov/2018
5 Exposición final del sistema de información propuesto 30% 03/Dic/2018
6 Prácticas de laboratorio 10% 05/Dic/2018
7 Portafolio de evidencias 10% 06/Dic/2018
Total de puntos para la segunda unidad 100%
4.1. Modelo de componentes
El diagrama de componentes es similar a un
diagrama de clases, sólo que es más como una vista
superficial de la arquitectura del sistema.
4.1. Modelo de componentes
El diagrama de componentes muestra los
componentes del sistema, como un archivo de clase,
un paquete, las bibliotecas compartidas, una base
de datos, etcétera, y la forma en que se relacionan
entre sí.
Los componentes individuales en un diagrama de
componentes se consideran con más detalle dentro
de otros diagramas de UML, como los diagramas
de clases y los diagramas de casos de uso.
4.1. Modelo de componentes
El diagrama de componentes proporciona una
visión física de la construcción del sistema de
información.
Muestra la organización de los componentes
software, sus interfaces y las dependencias entre
ellos.
4.1. Modelo de componentes
Descripción
Los elementos de estos diagramas son los componentes
software y las dependencias entre ellos.
Un componente es un módulo de software que puede ser
código fuente, código binario, un ejecutable, o una librería
con una interfaz definida. Una interfaz establece las
operaciones externas de un componente, las cuales
determinan una parte del comportamiento del mismo.
Además se representan las dependencias entre
componentes o entre un componente y la interfaz de otro, es
decir uno de ellos usa los servicios o facilidades del otro.
4.1. Modelo de componentes
Descripción
Estos diagramas pueden incluir paquetes que
permiten organizar la construcción del sistema de
información en subsistemas y que recogen aspectos
prácticos relacionados con la secuencia de
compilación entre componentes, la agrupación de
elementos en librerías, etc.
4.1. Modelo de componentes
Objetivo
Se utilizan para modelar la vista estática de un sistema.
Muestra la organización y las dependencias entre un
conjunto de componentes. No es necesario que un
diagrama incluya todos los componentes del sistema,
normalmente se realizan por partes. Cada diagrama
describe un apartado del sistema.
Uno de los usos principales es que puede servir para
ver que componentes pueden compartirse entre
sistemas o entre diferentes partes de un sistema.
4.1. Modelo de componentes
Notación
Componente
Un componente se representa como un rectángulo, con dos
pequeños rectángulos superpuestos perpendicularmente en el
lado izquierdo.
Para distinguir distintos tipos de componentes se les puede
asignar un estereotipo, cuyo nombre estará́ dentro del
símbolo: << ... >>
4.1. Modelo de componentes
Notación
Interfaz
Se representa como un pequeño circulo situado junto al
componente que lo implementa y unido a el por una línea
continua. La interfaz puede tener un nombre que se escribe
junto al circulo. Un componente puede proporcionar más de
una interfaz.
4.1. Modelo de componentes
Notación
Paquete
Un paquete se representa con un icono de carpeta.
Relación de dependencia
Una relación de dependencia se representa mediante una
línea discontinua con una flecha que apunta al componente o
interfaz que provee del servicio o facilidad al otro. La relación
puede tener un estereotipo que se coloca junto a la línea,
entre el símbolo: <<...>>
4.1. Modelo de componentes
Ejemplo
Sistema encargado de la gestión de los prestamos y reservas de libros y revistas en
una biblioteca. El lenguaje de desarrollo será Java, y los accesos a la información
del prestatario serán mediante un paquete de Base de Datos.
4.1. Modelo de componentes
Pasos para la elaboración de un diagrama de componentes
Previamente al diagrama de componentes debemos de tener hecho
el diagrama de clases.
Se debe identificar a todos las clases que participaran en el sistema
o subsistema a desarrollar.
Una vez identificado las clases, se procede a identificar sus
métodos.
Estos métodos pasaran a ser módulos con líneas de código
independientes.
Estos módulos serán los componentes de nuestro diagrama.
Estos componentes se relacionan entre si por medio de sus
interfaces.
4.2. Modelo de despliegue
El objetivo de estos diagramas es mostrar la
disposición de las particiones físicas del sistema de
información y la asignación de los componentes
software a estas particiones.
Es decir, las relaciones físicas entre los componentes
software y hardware en el sistema a entregar.
4.2. Modelo de despliegue
Descripción
En estos diagramas se representan dos tipos de
elementos, nodos y conexiones, así́ como la
distribución de componentes del sistema de
información con respecto a la partición física del
sistema.
4.2. Modelo de despliegue
Notación
Nodo
Se representa con la figura de un cubo. El nodo se
etiqueta con un nombre representativo de la partición
física que simboliza. Se pueden asociar a los nodos
subsistemas de construcción.
Conexión
Las conexiones se representan con una línea continua
que une ambos nodos y pueden tener una etiqueta que
indique el tipo de conexión. (ejemplo: canal, red,
protocolo, etc.)
4.3 Planeación del desarrollo de sistemas
de información.
A finales de los años sesenta del siglo pasado, se eligió a un
entusiasta joven ingeniero para que “escribiera” un programa de
computadora para una aplicación de fabricación automatizada. La
razón para su selección fue simple.
Él era la única persona en su grupo técnico que asistió a un
seminario de programación de computadoras. Sabía los pros y los
contras del lenguaje ensamblador y de FORTRAN, pero nada
conocía acerca de ingeniería de software incluso menos acerca de
la calendarización y el seguimiento de proyectos.
Su jefe le dio los manuales apropiados y una descripción verbal de
lo que tenía que hacer. Se le informó que el proyecto debía estar
terminado en dos meses.
4.3 Planeación del desarrollo de sistemas
de información.
Leyó los manuales, consideró su enfoque y comenzó a escribir el código.
Después de dos semanas, el jefe lo llamó a su oficina y le preguntó sobre
cómo iban las cosas.
“Realmente grandiosas”, dijo el ingeniero con entusiasmo juvenil. “Esto fue
mucho más simple de lo que pensé. Probablemente tenga ya un avance de
75 por ciento”.
El jefe sonrió y alentó al joven ingeniero a seguir con el buen trabajo.
Planearon reunirse de nuevo en una semana. Una semana después, el jefe
llamó al ingeniero a su oficina y le preguntó: “¿Dónde estamos?”
“Todo está bien”, dijo el joven, “pero encontré algunos tropiezos. Los
allanaré y pronto estaré de vuelta en el camino”. “¿Qué te parece la fecha
límite?”, preguntó el jefe. “No hay problema”, dijo el ingeniero. “tengo un
avance de cerca de 90 por ciento”.
4.3 Planeación del desarrollo de sistemas
de información.
Aunque existen muchas razones por las que el software se entrega tardíamente, la
mayoría pueden rastrearse en una o más de las siguientes causas fundamentales:
Una fecha límite irreal establecida por alguien externo al equipo de software y
que fuerza a los gerentes y profesionales.
Requerimientos del cliente variables que no se reflejan en cambios del
calendario.
Una honesta subestimación de la cantidad de esfuerzo y/o número de recursos
que se requerirán para hacer el trabajo.
Riesgos predecibles y/o impredecibles que no se consideraron cuando comenzó
el proyecto.
4.3 Planeación del desarrollo de sistemas
de información.
Dificultades humanas que no podían preverse por anticipado.
Falta de comunicación entre el personal del proyecto que da como
resultado demoras.
Falta de comunicación entre el equipo de trabajo que se traduce en
retrasos.
Una falla por parte de la administración del proyecto para reconocer que
el proyecto tiene retrasos en el calendario y una falta de acción para
corregir el problema.
