Está en la página 1de 35

1

Prefacio:
La asignatura de Anlisis y Diseo de
Sistemas, es de naturaleza terico -
prctica. El contenido ha sido
elaborado para orientar al uso de los
diferentes aspectos en una
planificacin coherente de los
conocimientos informticos en la
estructuracin del desarrollo de un Sistema de Informacin. Lo cual se aplica en el
campo de la empresa donde la bsqueda de profesionales con dichos conocimiento en
esta materia es constante y muy bien remunerada. Propone desarrollar en el estudiante
las competencias para comprender el fundamento y aplicacin de las principales
tcnicas en el diseo de Sistemas de Informacin.

COMPETENCIA:
Disear, efectuar y negociar el uso de las diferentes tecnologas de Informacin y
Comunicacin de una Institucin, a partir del anlisis de sus requerimientos, teniendo
en cuenta los criterios de calidad, seguridad y tica profesionales propiciando el trabajo
en equipo Dominar las habilidades y destrezas sobre la metodologa del sistema de
informacin actual, dando un desarrollo estructura y orientado a objetos, analizando y
comparando el sistema real con un sistema de informacin, utilizando los diferentes
esquemas UM L.

Comprende cuatro Unidades de Aprendizaje:


Unidad Didctica I: Conceptos bsicos del anlisis y diseo
Unidad Didctica II: Procedimiento para el anlisis y diseo de sistema
Unidad Didctica III: Fundamento del desarrollo del diseo orientado a objetos
Unidad Didctica IV: Desarrollo de diagramas orientado a objetos

2
ndice del Contenido
I. PREFACIO
02

II. DESARROLLO DE LOS CONTENIDOS


03 - 24

UNIDAD DIDACTICA I: CONCEPTOS BASICOS DEL ANALISI Y DISEO 04-10

UNIDAD DIDACTICA II: PROCEDIMIENTO PARA EL ANALISIS Y DISEO DE SISTEMA


11-20

UNIDAD DIDACTICAIII: FUNDAMENTO DEL DESARROLLO DEL DISEO ORIENTADO A OBJETOS 21-26

UNIDAD DIDACTICA IV: DESARROLLO DE DIAGRAMAS ORIENTADO A OBJETOS 27-34

35
III. TRABAJO DE INVESTIGACION

35
IV. FUENTES DE INFORMACIN

3
UNIDAD DIDCTICA I: CONCEPTOS
BSICOS DEL ANLISIS Y DISEO
Introduccin.- Las organizaciones han reconocido,
desde hace mucho, la importancia de administrar
recursos principales tales como la mano de obra y las
materias primas. La informacin se ha colocado en un
lugar adecuado como recurso principal. Los tomadores
de decisiones estn comenzando a comprender que la
informacin no es slo un sub producto de la conduccin, sino que a la vez alimenta a
los negocios y puede ser el factor crtico para la determinacin del xito o fracaso de
stos. Los sistemas de informacin son desarrollados con propsitos diferentes
dependiendo de las necesidades del negocio. Los sistemas de procesamiento de
transacciones, TPS, funcionan al nivel operacional de la organizacin, los sistemas de
automatizacin de oficina, OAS, y los sistemas de trabajo de conocimiento, KWS, que
dan cabida al trabajo a nivel de conocimiento. Los sistemas de ms alto nivel incluyen
a los sistemas de apoyo a decisiones, DSS, as como a los sistemas de informacin
gerencial, MIS. Los sistemas expertos aplican la experiencia de los tomadores de
decisiones para resolver problemas especficos estructurados. Al nivel estratgico de la
administracin encontramos sistemas de apoyo a ejecutivos, ESS y los sistemas de
apoyo a decisiones de grupo, GDSS ayudan a la toma de decisiones.

LA NECESIDAD DEL ANLISIS Y DISEO DE SISTEMAS.


El anlisis y diseo de sistemas, tal como es ejecutado por los analistas de sistemas,
busca analizar sistemticamente la entrada de datos o el flujo de datos, el proceso o
transformacin de los datos, el almacenamiento de datos y la salida de informacin
dentro del contexto de un negocio particular. Adems, el diseo y anlisis de sistemas
es usado para analizar, disear e implementar mejoras en el funcionamiento de los
negocios que pueden ser logradas por medio del uso de sistemas de informacin
computarizados. La instalacin de un sistema sin la planeacin adecuada lleva a
grandes frustraciones, y frecuentemente causa que el sistema deje de ser usado.

El analista de sistemas frecuentemente acta


como consultor y, por lo tanto, puede ser
contratado especficamente para que se
encargue de los asuntos de los sistemas de
informacin dentro de un negocio. Esto puede ser
una ventaja, debido a que los consultores
externos pueden llevar con ellos una perspectiva
fresca que no poseen otros miembros de la
organizacin. Pero tambin puede decirse que los
analistas externos estn en desventaja, debido a que la verdadera cultura
organizacional nunca puede ser conocida por un extrao.

4
CONCEPTOS BSICOS DEL ANLISIS Y DISEO
El concepto y los elementos o componentes del sistema
Individuos participantes
Son todas aquellas personas cuyo trabajo tiene que ver con la creacin, la recoleccin,
la distribucin y el uso de la informacin.
Propietarios de sistemas
Personas que patrocinan y promueven los SI.
Son los directivos: director general o directores de operaciones
Las funciones son:
Fijar el presupuesto y los plazos para el desarrollo y mantenimiento del SI
Usuarios de sistemas
Personas que utilizan los SI de forma regular para capturar, introducir, validar,
transformar y almacenar datos e informacin.
Son los ms importantes en el desarrollo de un SI
Internos: personal administrativo, profesionales y tcnicos, gestores y directivos
Externos: clientes, proveedores, partners, trabajadores externos

Diseadores de sistemas
Expertos en tecnologa que resuelven las necesidades y las restricciones
manifestadas por los usuarios de la empresa mediante recursos tecnolgicos.
Administracin de datos (tecnologas de bases de datos)
Arquitectura de redes (tecnologas de comunicacin)
Diseo web (tecnologas web)
La seguridad (tecnologas de seguridad y privacidad)
Analistas de sistemas
Persona que estudia los problemas y las necesidades de una empresa para
determinar cmo podran combinarse los recursos humanos, los procesos, los datos
y la tecnologa de la informacin para obtener mejoras en la empresa.
Personas capaces de corregir situaciones poco eficientes, as como, anticiparse a
problemas que puedan surgir dentro de la organizacin.

Habilidades
o Conocimientos generales de la empresa
o Capacidad de resolver problemas
o Tcnicas de comunicacin interpersonal
o Flexibilidad y capacidad de adaptacin
o Carcter y tica
o Mejorar los conocimientos en tecnologa y sistemas de informacin
o Experimentacin y dominio de la programacin informtica
Project Manager
Profesional experimentado que acepta la responsabilidad de planificar, supervisar y
controlar proyectos en lo que concierne al calendario, el presupuesto, la satisfaccin
del cliente, las normas tcnicas y la calidad del sistema.

5
Datos e informacin
Diferencia
echos y cifras con existencia propia e independiente con poco significado
para el usuario
oras que produce un trabajador, tiempo que tarda.

Informacin.
onjunto de datos procesados con significado, y dotados de relevancia
y propsito.
recio hora por horas trabajadas nos dan informacin de lo que ganar un
empleado
Procesos de negocio
Los sistemas de informacin tienen que alcanzar el objetivo de mejorar la eficiencia de
los procesos de negocio. Deben implicarse los propietarios y los usuarios del sistema
definir y acotar las funciones de negocio (grupo de procesos que
interactan entre ellos: ventas, produccin, logstica, contabilidad)

a acontecimientos de negocio: pedido, factura, alta cliente, albarn)

Tecnologa de la informacin

telecomunicaciones (redes de datos, imgenes y voz)


de los sistemas de informacin
Caractersticas y tipos de los sistemas de informacin
Existen varios tipos de Sistemas de Informacin, desde el punto de vista administrativo
stos se pueden clasificar en una forma de pirmide.

6
Nivel operativo.- Se utilizan para realizar un seguimiento de las actividades y
operaciones bsicas de una organizacin.
Sistema de Procesamiento de Transacciones (TPS).- Recolectan, almacenan,
modifican y recuperan la informacin generada por las transacciones producidas en
una organizacin. Si durante una transaccin se produce un error, el TPS debe ser
capaz de deshacer las operaciones realizadas hasta ese momento. Es muy til para el
procesamiento de transacciones on-line.
Nivel de conocimiento.- Se utilizan para el mejoramiento de la calidad de los servicios
de la organizacin y aporte de nuevos conocimientos, adems de incrementar la
productividad de los usuarios del sistema.

Sistemas de Conocimiento (KWS).- Auxilian a los


trabajadores en la creacin e integracin de nuevo
conocimiento en la organizacin. Estn diseados
para aumentar la productividad de los trabajadores.
Sistemas de Automatizacin de Oficina
(OAS).- A plicaciones destinadas a ayudar al
trabajo diario del administrativo de una
organizacin, forman parte de este tipo de
software los procesadores de textos, las hojas
de clculo, los editores de presentaciones, los
clientes de correo electrnico, etc.
Nivel administrativo.- Son utilizados por los administradores de nivel medio en la
toma de decisiones. Tratan y comparan resultados relevantes para la compaa, y
estudian sus trayectorias.
Sistemas de Informacin Gerencial (MIS).- Son el resultado de interaccin
colaborativa entre personas, tecnologas y procedimientos. Apoyan a nivel
administrativo entregando informacin til para el planteamiento, control y toma de
decisiones.

Sistemas de Apoyo a la Toma de Decisiones (DSS).- Herramienta para realizar


el anlisis de las diferentes variables de un negocio con la finalidad de apoyar el
proceso de toma de decisiones. Su principal caracterstica es la capacidad de
anlisis multidimensional (OLAP) que permite profundizar en la informacin hasta
llegar a un alto nivel de detalle, analizar datos desde diferentes perspectivas,
realizar proyecciones de informacin para pronosticar lo que puede ocurrir en el
futuro, anlisis de tendencias, anlisis prospectivo, etc.
Nivel estratgico.- Estn basados en los resultados estratgicos a largo plazo de
la compaa, son tiles para poder hacer frente a los impactos producidos por
cambios en los negocios.

7
Sistemas de Soporte Gerencial (SSG).- Trabajan con informacin interna y
externa a la organizacin y estn diseados para abordar la toma de decisiones
que requieren juicio, evaluacin y comprensin.
Sistemas Expertos (SE).- Es una aplicacin informtica capaz de solucionar un
conjunto de problemas que exigen un gran conocimiento sobre un determinado
tema. Emulan el comportamiento de un experto en un dominio concreto y en
ocasiones son usados por stos. Con los sistemas expertos se busca una mejor
calidad y rapidez en las respuestas dando as lugar a una mejora de la productividad
del experto.

DEFINICIN DE LA INFORMACIN, CARACTERSTICAS


Un sistema de informacin es un conjunto de
elementos que interactan entre s con el fin de
apoyar las actividades de una empresa o negocio.
El equipo computacional (hardware) necesario
para que el sistema de informacin pueda
operar.
El recurso humano que interacta con el
Sistema de Informacin, el cual est formado
por las personas que utilizan el sistema.

Un sistema de informacin realiza cuatro actividades bsicas:


Entrada de Informacin: es el proceso mediante el cual el Sistema de Informacin
toma los datos que requiere para procesar la informacin. Las entradas pueden ser
manuales o automticas. Las manuales son aquellas que se proporcionan en forma
directa por el usuario, mientras que las automticas son datos o informacin que
provienen o son tomados de otros sistemas o mdulos. Esto ltimo se denomina
interfaces automticas.
Almacenamiento de informacin: el almacenamiento es una de las actividades o
capacidades ms importantes que tiene una computadora, ya que a travs de esta
propiedad el sistema puede recordar la informacin guardada en la seccin o proceso
anterior. Esta informacin suele ser almacenada en estructuras de informacin
denominadas archivos. La unidad tpica de almacenamiento son los discos magnticos
o discos duros y los discos compactos (CD-ROM).
Procesamiento de Informacin: es la capacidad del
Sistema de Informacin para efectuar clculos de
acuerdo con una secuencia de operaciones
preestablecida. Estos clculos pueden efectuarse con
datos introducidos recientemente en el sistema o bien
con datos que estn almacenados. Esta caracterstica
de los sistemas permite la transformacin de datos fuente en informacin que puede ser
utilizada para la toma de decisiones, lo que hace posible, entre otras cosas, que un
tomador de decisiones genere una proyeccin financiera a partir de los datos que
contiene un estado de resultados o un balance general de un ao base.

8
Salida de Informacin: la salida es la capacidad de un Sistema de Informacin para
sacar la informacin procesada o bien datos de entrada al exterior. Las unidades tpicas
de salida son las impresoras, terminales, cintas magnticas, la voz, los graficadores y
los plotters, entre otros. Es importante aclarar que la salida de un Sistema de
Informacin puede constituir la entrada a otro Sistema de Informacin o mdulo. En este
caso, tambin existe una interface automtica de salida. Por ejemplo, el Sistema de
Control de Clientes tiene una interface automtica de salida con el Sistema de
Contabilidad, ya que genera las plizas contables de los movimientos procesales de los
clientes.

DEFINICIN, OPERACIONES Y LA TOMA DE DECISIONES


* La toma de decisiones, es un trmino reservado para la accin de
elegir entre varias alternativas.
* La toma de decisiones, es un proceso de pensamiento que ocupa
toda la actividad que tiene por finalidad la solucin de problemas.
* Todo aspecto que refleja el esfuerzo humano involucra actividades
con un propsito en las que deben resolverse los problemas y tomar
decisiones.
* La toma de decisiones puede verse como un procedimiento, un
ciclo que contiene varios crculos.
* La toma de decisiones, es necesaria cuando tenemos un problema que resolver, o
necesidades que satisfacer.
* El paso para definir el problema, puede considerarse como un sub problema del
problema principal, es decir, un circuito dentro de otro circuito, en el ciclo de la toma
de decisiones.

* Los sistemas de informacin son de vital importancia en cualquier tipo de informacin,


ya que nos proporcionan las herramientas necesarias para un tomador de decisiones
pueda realizar su trabajo ptimamente.
* Dichos sistemas al proporcionar la informacin necesaria en el preciso momento y con
la mayor eficiencia posible, ayuda a que la empresa crezca y se desarrolle.
Los analistas, al trabajar con los empleados y administradores, deben estudiar los
procesos de una empresa para dar respuesta a las siguientes preguntas:
1.- Qu es lo que se hace?
2.- Cmo se hace?
3.- Con que frecuencia se presenta?
4.- Qu tan grande es el volumen de transacciones o de decisiones?
5.- Cul es el grado de eficiencia con el que se efectan las tareas?
6.- Existe algn problema?
7.- Si existe un problema, que tan grave es?
8.- Si existe un problema, cual es la causa que lo origina?

9
Para contestar estas preguntas, el analista conversa con varias personas, para
reunir detalles relacionados con los procesos de la empresa, sus opiniones sobre
por qu ocurren las cosas, las soluciones que proponen y sus ideas para cambiar el
proceso.
Se emplean cuestionarios para obtener esta informacin cuando no es posible
entrevistar en forma personal, a los miembros de grupos grandes dentro de la
organizacin. As mismo se requiere del estudio de manuales y reportes, la
observacin directa de las actividades que se realizan en algunos casos formas y
documentos para comprender mejor el proceso en tu totalidad
Durante la fase de pruebas de sistemas, el sistema se emplea de forma experimental
para asegurarse de que el software no tenga fallas, es decir que funciona de acuerdo
con las especificaciones y en la forma en que los usuarios esperan que lo haga.

En muchas organizaciones, las pruebas son conducidas por personas ajenas al grupo
que escribi los programas originales; con esto se persigue asegurar, por una parte, que
las pruebas sean completas e imparciales y, por otra, que el software sea ms confiable.
La evaluacin de un sistema se lleva a cabo para identificar puntos dbiles y fuertes.
Los sistemas para el soporte de decisiones tienen como finalidad ayudar a los directivos
que enfrentan problemas de decisin nicos (no recurrentes).
Con frecuencia un aspecto importante de esas decisiones es
determinar qu informacin es la que se debe considerar.
Dada la dificultad de predecir las necesidades de informacin,
es imposible disear de antemano los reportes.
Este tipo de sistemas debe ser bastante flexible para
satisfacer las necesidades cambiantes de los directivos. Los
sistemas para el soporte de decisiones son una fuente de
informacin pero no reemplazan el buen juicio que todo
directivo debe tener. La evaluacin ocurre a lo largo de
cualquiera de las siguientes dimensiones. El establecimiento de un buen proceso de
solucin de problemas en una organizacin requiere el compromiso, la cooperacin y la
planificacin de todas las partes implicadas.

Un error en un sistema de produccin puede


no ser cuestin de vida o muerte, pero s puede
significar una importante prdida para el
negocio. Los rpidos cambios en la industria de
hoy hacen que los problemas tcnicos formen
parte de todos los entornos, y por ello es
importante destinar recursos a desarrollar un
proceso que permita tratarlos de forma eficaz.

10
UNIDAD DIDCTICA II: PROCEDIMIENTO
PARA EL ANLISIS Y DISEO DE SISTEMA
seo.
Anlisis de Sistemas de Informacin.- Es un
conjunto de procedimientos o programas relacionados
de manera que juntos forman una sola unida, esto se
lleva a cabo teniendo en cuenta ciertos principios:
Debe presentarse y entenderse el dominio de la
informacin de un problema.
Defina las funciones que debe realizar el Software.
Represente el comportamiento del software a
consecuencias de acontecimientos externos.
Divida en forma jerrquica los modelos que representan la informacin, funciones y
comportamiento.

El proceso debe partir desde la informacin esencial hasta el detalle de la


Implementacin. La funcin del Anlisis puede ser dar soporte a las actividades de un
negocio, o desarrollar un producto que pueda venderse para generar beneficios. Un
Anlisis de Sistema se lleva a cabo teniendo en cuenta los siguientes objetivos en
mente:
Identifique las necesidades del Cliente.
Evale que conceptos tiene el cliente del sistema para establecer su viabilidad.
Realice un Anlisis Tcnico y econmico.
Asigne funciones al Hardware, Software, personal, base de datos, y otros elementos
del Sistema.
Establezca las restricciones de presupuestos y planificacin temporal.
Cree una definicin del sistema que forme el fundamento de todo el trabajo de
Ingeniera.

Para lograr estos objetivos se requiere tener un gran


conocimiento y dominio del Hardware y el Software, as como
de la Ingeniera humana (Manejo y Administracin de
personal), y administracin de base de datos.
El objetivo del anlisis de sistema de informacin, es la
identificacin de Necesidades.
Es el primer paso del anlisis del sistema, en este proceso
el Analista se rene con el cliente y/o usuario (un
representante institucional, departamental o cliente
particular), e identifican las metas globales, se analizan las
perspectivas del cliente, sus necesidades y requerimientos, sobre la planificacin
temporal y presupuestal, lneas de mercadeo y otros puntos que puedan ayudar a la
identificacin y desarrollo del proyecto.

11
Antes de su reunin con el analista, el cliente prepara un documento conceptual del
proyecto, aunque es recomendable que este se elabore durante la comunicacin Cliente
analista, ya que de hacerlo el cliente solo de todas maneras tendra que ser
modificado, durante la identificacin de las necesidades.
Estudio de Viabilidad, muchas veces cuando se emprende el desarrollo de un
proyecto de Sistemas los recursos y el tiempo no son realistas para su materializacin
sin tener prdidas econmicas y frustracin profesional. La viabilidad y el anlisis de
riesgos estn relacionados de muchas maneras, si el riesgo del proyecto es alto, la
viabilidad de producir software de calidad se reduce, sin embargo se deben tomar en
cuenta cuatro reas principales de inters:
Viabilidad econmica.- Una evaluacin de los costos de desarrollo, comparados con
los ingresos netos o beneficios obtenidos del producto o Sistema desarrollado.
Viabilidad Tcnica.- Un estudio de funciones, rendimiento y restricciones que
puedan afectar la realizacin de un sistema aceptable.
Viabilidad Legal.- Es determinar cualquier posibilidad de infraccin, violacin o
responsabilidad legal en que se podra incurrir al desarrollar el Sistema.
Alternativas.- Una evaluacin de los enfoques alternativos del desarrollo del
producto o Sistema.

El estudio de la viabilidad puede documentarse como un informe aparte para la alta


gerencia.
Anlisis econmico y tcnico de los sistemas de informacin
El anlisis econmico incluye lo que llamamos, el anlisis de costos beneficios,
significa una valoracin de la inversin econmica comparado con los beneficios que se
obtendrn en la comercializacin y utilidad del producto o sistema.
Modelado de la arquitectura del sistema.
Cuando queremos dar a entender mejor lo que
vamos a construir en el caso de edificios,
Herramientas, Aviones, Maquinas, se crea un
modelo idntico, pero en menor escala (ms
pequeo). Sin embargo cuando aquello que
construiremos es un Software, nuestro modelo
debe tomar una forma diferente, deben representar
todas las funciones y sub funciones de un Sistema.

ESPECIFICACIONES DEL SISTEMA


Es un Documento que sirve como fundamento para la Ingeniera Hardware, software,
Base de datos, e ingeniera Humana. Describe la funcin y rendimiento de un Sistema
basado en computadoras y las dificultades que estarn presentes durante su desarrollo.
Las Especificaciones de los requisitos del software se producen en la terminacin de la
tarea del anlisis.

12
Diseo de sistemas de informacin.- Se define el proceso de aplicar ciertas
tcnicas y principios con el propsito de definir un dispositivo, un proceso o un Sistema,
con suficientes detalles como para permitir su interpretacin y realizacin fsica
La etapa del Diseo del Sistema de informacin encierra cuatro etapas:
El diseo de los datos.- Trasforma el modelo de
dominio de la informacin, creado durante el anlisis,
en las estructuras de datos necesarios para
implementar el Software.
El Diseo Arquitectnico.- Define la relacin entre
cada uno de los elementos estructurales del
programa.
El Diseo de la Interfaz.- Describe como se comunica
el Software consigo mismo, con los sistemas que
operan junto con l y con los operadores y usuarios que lo emplean.
El Diseo de procedimientos.- Transforma elementos estructurales de la arquitectura
del programa. La importancia del Diseo del Software se puede definir en una sola
palabra Calidad, dentro del diseo es donde se fomenta la calidad del Proyecto. El
Diseo es la nica manera de materializar con precisin los requerimientos del cliente.

El Diseo del Software es un proceso y un modelado a la vez. El proceso de Diseo es


un conjunto de pasos repetitivos que permiten al diseador describir todos los aspectos
del Sistema a construir. A lo largo del diseo se evala la calidad del desarrollo del
proyecto con un conjunto de revisiones tcnicas:
El diseo debe implementar todos los requisitos explcitos contenidos en el modelo de
anlisis y debe acumular todos los requisitos implcitos que desea el cliente.
Debe ser una gua que puedan leer y entender los que construyan el cdigo y los que
prueban y mantienen el Software. El Diseo debe proporcionar una completa idea de lo
que es el Software, enfocando los dominios de datos, funcional y comportamiento desde
el punto de vista de la Implementacin.

Para evaluar la calidad de una presentacin del diseo, se deben establecer criterios
tcnicos para un buen diseo como son:
Un diseo debe presentar una organizacin
jerrquica que haga un uso inteligente del
control entre los componentes del software.
El diseo debe ser modular, es decir, se
debe hacer una particin lgica del Software en
elementos que realicen funciones y sub
funciones especficas.
Un diseo debe contener abstracciones de
datos y procedimientos.

13
Debe producir mdulos que presenten caractersticas de funcionamiento
independiente.
Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre
los mdulos y el entorno exterior.
Debe producir un diseo usando un mtodo que pudiera repetirse segn la
informacin obtenida durante el anlisis de requisitos de Software.
Estos criterios no se consiguen por casualidad. El proceso de Diseo del Software exige
buena calidad a travs de la aplicacin de principios fundamentales de Diseo,
Metodologa sistemtica y una revisin exhaustiva.
Cuando se va a disear un Sistema de Computadoras se debe tener presente que el
proceso de un diseo incluye, concebir y planear algo en la mente, as como hacer un
dibujo o modelo o croquis.

Diseo de la Salida.- En este caso salida se refiere a los resultados e informaciones


generadas por el Sistema, Para la mayora de los usuarios la salida es la nica razn
para el desarrollo de un Sistema y la base de evaluacin de su utilidad. Sin embargo
cuando se realiza un sistema, como analistas deben realizar lo siguiente:
Determine qu informacin presentar.- Decidir si la informacin ser presentada en
forma visual, verbal o impresora y seleccionar el medio de salida. Disponga la
presentacin de la informacin en un formato aceptable. Decida cmo distribuir la salida
entre los posibles destinatarios.
Diseo de Archivos.- Incluye decisiones con respecto a la naturaleza y contenido del
propio archivo, como si se fuera a emplear para guardar detalles de las transacciones,
datos histricos, o informacin de referencia.
Entre las decisiones que se toman durante el diseo de archivos, se encuentran las
siguientes:
Los datos que deben incluirse en el formato de registros contenidos en el archivo.
La longitud de cada registro, con base en las caractersticas de los datos que
contenga.
La secuencia a disposicin de los registros dentro del archivo (La estructura de
almacenamiento que puede ser secuencial, indexada o relativa).

No todos los sistemas requieren del diseo de todos los archivos, ya que la mayora de
ellos pueden utilizar los del viejo Sistema y solo tenga que enlazarse el nuevo Sistema
al Archivo maestro donde se encuentran los registros.
Diseo de Interacciones con la Base de Datos.- La mayora de los sistemas de
informacin ya sean implantado en sistemas de cmputos grandes o pequeos, utilizan
una base de datos que pueden abarcar varias aplicaciones, por esta razn estos
sistemas utilizan u administrador de base de datos, en este caso el diseador no
construye la base de datos sino que consulta a su administrador para ponerse de
acuerdo en el uso de esta en el sistema.

14
Herramientas para el Diseo de Sistemas de Informacin
Apoyan el proceso de formular las caractersticas que el
sistema debe tener para satisfacer los requerimientos
detectados durante las actividades del anlisis:
Herramientas de especificacin.- Apoyan el proceso
de formular las caractersticas que debe tener una
aplicacin, tales como entradas, Sali das,
procesamiento y especificaciones de control. Muchas
incluyen herramientas para crear especificaciones
de datos.
Herramientas para presentacin.- Se utilizan para describir la posicin de datos,
mensajes y encabezados sobre las pantallas de las terminales, reportes y otros
medios de entrada y salida.
Herramientas para el desarrollo de Sistemas.- Estas herramientas nos ayudan como
analistas a trasladar diseos en aplicaciones funcionales.
Herramientas para Ingeniera de Software.- Apoyan el Proceso de formular diseos
de Software, incluyendo procedimientos y controles, as como la documentacin
correspondiente.

Generadores de cdigos.- Producen el cdigo


fuente y las aplicaciones a partir de especificaciones
funcionales bien articuladas.
Herramientas para pruebas.- Apoyan la fase de la
evaluacin de un Sistema o de partes del mismo contra las
especificaciones. Incluyen facilidades para examinar la
correcta operacin del Sistema as como el grado de
perfeccin alcanzado en comparacin con las
expectativas.
La revolucin del procesamiento de datos de manera computarizada, junto con las
prcticas de diseo sofisticados est cambiando de forma dramtica la manera en que
se trasladan las especificaciones de Diseo d Sistemas de Informacin funcionales

Entender las diferentes etapas del ciclo de vida del desarrollo de sistemas
El Ciclo de Vida del Desarrollo de Sistemas (SDLC) es una metodologa de sistemas
usada para facilitar el desarrollo de los sistemas de informacin. Adems, el SDLC
ayuda a los gestores de proyecto con la planificacin del desarrollo y la puesta en
marcha de un sistema de informacin que rena los requisitos del usuario, y que sea
completado a tiempo y dentro de los lmites del presupuesto. Con el SDLC, un
administrador de proyecto gestiona de forma efectiva las tareas y detalles de un
proyecto de desarrollo de sistemas, y comunica las fechas objetivos importantes a las
personas involucradas o afectadas por el proyecto. Las fases del SDLC son:

15
Planificacin conceptual: La planificacin conceptual es la primera fase del ciclo de
vida del desarrollo de sistemas. En esta fase, las personas importantes que participan en
el proyecto o interesados definen el sistema propuesto y determinan el alcance del
proyecto. Adems, se determinan las limitaciones de factores como los recursos,
presupuesto y tiempo.
Definicin de requisitos: La siguiente fase es la de la definicin de requisitos. Despus
de que los interesados establezcan el alcance del proyecto, los especialistas en
tecnologas de la informacin (TIC) trabajan con los usuarios finales para definir los
requisitos de negocio del sistema. Cuando los especialistas de TIC recogen todos los
requisitos, se renen de nuevo con los usuarios finales para verificar los requisitos y
conseguir la validacin por parte de los usuarios.
Diseo: En la fase del diseo, los especialistas de TIC transforman los requisitos en
requisitos tcnicos. Inicialmente, los desarrolladores crean un diseo tcnico preliminar
para tratar todos los requisitos de negocio del sistema definidos en la fase de definicin
de requisitos. Cuando el diseo preliminar ha terminado, los desarrolladores hacen un
diseo tcnico detallado, que define todas las funciones tcnicas necesarias para
implementar el sistema.

Desarrollo y pruebas: En la fase de desarrollo y pruebas, los desarrolladores


empiezan a desarrollar el sistema actual. Esto incluye crear el software y construir la
arquitectura adecuada de la base de datos del sistema. Las pruebas empiezan despus
de terminar la construccin de los componentes del sistema. Adems, los analistas que
aseguran la calidad verifican que el sistema rena los requisitos de negocio usando un
plan de pruebas detallado.
Puesta en marcha: Durante la puesta en marcha, TI distribuye el nuevo sistema a
todos los usuarios finales, para que puedan empezar a usarlo. Adems, los especialistas
de TI proporcionan la documentacin del sistema a los usuarios finales, que detallan
cmo usar el sistema. La formacin tambin es una parte importante de la fase de puesta
en marcha. Las sesiones de formacin deberan ser planteadas para cada grupo de
usuarios, para que los usuarios se puedan beneficiar del sistema ms adelante.
Operaciones y mantenimiento: En la fase de operaciones y mantenimiento, el nuevo
sistema pasa a modo de operacin total. TI controla el sistema para asegurar que el
sistema rena los requisitos de negocio pedidos. Adems, el personal de TI realiza
mantenimiento peridico en el sistema para asegurar que el sistema sigue funcionando
como se espera. El equipo de soporte tambin proporciona asistencia para el sistema y
resuelve los problemas informados.
Disposicin: La fase de disposicin ocurre al final del ciclo de vida del sistema. Cuando
un sistema ha completado su tiempo de vida y se retira, esta fase proporciona una serie
de pasos sistemticos para finalizar el sistema. Realizar esta fase asegura que la
informacin vital se mantenga para los negocios futuros o las necesidades del sistema.
Adems, la disposicin del sistema adecuada es necesaria para asegurar que un
componentes del sistema, datos, software y hardware se disponen de forma adecuada y
segn las normas de la compaa.

16
COMPRENDER CUL ES EL CICLO DE VIDA
DEL SOFTWARE
El trmino ciclo de vida del software describe el
desarrollo de software, desde la fase inicial hasta la
fase final. El propsito de este programa es definir las
distintas fases intermedias que se requieren para
validar el desarrollo de la aplicacin, es decir, para
garantizar que el software cumpla los requisitos para la
aplicacin y verificacin de los procedimientos de desarrollo: se asegura de que los
mtodos utilizados son apropiados. Estos programas se originan en el hecho de que es
muy costoso rectificar los errores que se detectan tarde dentro de la fase de
implementacin. El ciclo de vida permite que los errores se detecten lo antes posible y
por lo tanto, permite a los desarrolladores concentrarse en la calidad del software, en
los plazos de implementacin y en los costos asociados.

El ciclo de vida bsico de un software consta de los siguientes procedimientos:


Definicin de objetivos: definir el resultado del proyecto y su papel en la estrategia
global.
Anlisis de los requisitos y su viabilidad:
recopilar, examinar y formular los requisitos
del cliente y examinar cualquier restriccin
que se pueda aplicar.
Diseo general: requisitos generales de la
arquitectura de la aplicacin.
Diseo en detalle: definicin precisa de
cada subconjunto de la aplicacin.
Programacin (programacin e
implementacin): es la implementacin de un
lenguaje de programacin para crear las
funciones definidas durante la etapa de
diseo.

Prueba de unidad: prueba individual de cada subconjunto de la aplicacin para


garantizar que se implementaron de acuerdo con las especificaciones.
Integracin: para garantizar que los diferentes mdulos se integren con la
aplicacin. ste es el propsito de la prueba de integracin que est
cuidadosamente documentada.
Prueba beta (o validacin), para garantizar que el software cumple con las
especificaciones originales.
Documentacin: sirve para documentar informacin necesaria para los usuarios del
software y para desarrollos futuros.
Implementacin Mantenimiento: para todos los procedimientos correctivos
(mantenimiento correctivo) y las actualizaciones secundarias del software
(mantenimiento continuo).

17
El orden y la presencia de cada uno de estos
procedimientos en el ciclo de vida de una
aplicacin dependen del tipo de modelo de ciclo
de vida acordado entre el cliente y el equipo de
desarrolladores.
Modelos de ciclo de vida
Para facilitar una metodologa comn entre el
cliente y la compaa de software, los modelos
de ciclo de vida se han actualizado para reflejar
las etapas de desarrollo involucradas y la
documentacin requerida, de manera que cada
etapa se valide antes de continuar con la siguiente etapa. Al final de cada etapa se
arreglan las revisiones de manera que (texto faltante).

Modelo en cascada
Se define como una
secuencia de fases en la
que al final de cada una de
ellas se rene la
documentacin para
garantizar que cumple las
especificaciones y los
requisitos antes de pasar a
la fase siguiente:
Modelo V
El modelo de ciclo de vida
V proviene del principio que
establece que los
procedimientos utilizados para probar si la aplicacin cumple las especificaciones ya
deben haberse creado en la fase de diseo.

LENGUAJE DE MODELADO 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:

18
"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
Objectory. La versin 1.0 de UML fue liberada en Enero de 1997.
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 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.

MODELO
VISTA DIAGRAMA SIMBOLO REGLA
S

Las reglas son sintcticas, semnticas y pragmticas.


Vistas: las vistas muestran diferentes aspectos del sistema modelado. Una vista no es
una grfica, pero s una abstraccin que consiste en un nmero de diagramas y todos
esos diagramas juntos muestran una "fotografa" completa del sistema. Las vistas
tambin ligan el lenguaje de modelado a los mtodos o procesos elegidos para el
desarrollo.

19
Las diferentes vistas que UML tiene son:
Vista Use-Case: una vista que muestra la funcionalidad del sistema como la perciben
los actores externos.
Vista Lgica: muestra cmo se disea la funcionalidad dentro del sistema, en
trminos de la estructura esttica y la conducta dinmica del sistema.
Vista de Componentes: Muestra la organizacin de los componentes de cdigo.
Vista Concurrente: muestra la concurrencia en el sistema, direccionando los
problemas con la comunicacin y sincronizacin que estn presentes en un sistema
concurrente.
Vista de Distribucin: muestra la distribucin del sistema en la arquitectura fsica con
computadoras y dispositivos llamados nodos.

Diagramas: los diagramas son las grficas que describen el contenido de una vista.
UML tiene nueve tipos de diagramas que son utilizados en combinacin para proveer
todas las vistas de un sistema: diagramas de caso de uso, de clases, de objetos, de
estados, de secuencia, de colaboracin, de actividad, de componentes y de distribucin.
Smbolos o Elementos de modelo: los conceptos utilizados en los diagramas son los
elementos de modelo que representan conceptos comunes orientados a objetos, tales
como clases, objetos y mensajes, y las relaciones entre estos conceptos incluyendo la
asociacin, dependencia y generalizacin. Un elemento de modelo es utilizado en varios
diagramas diferentes, pero siempre tiene el mismo significado y simbologa.
Reglas o Mecanismos generales: proveen comentarios extras, informacin o
semntica acerca del elemento de modelo; adems proveen mecanismos de extensin
para adaptar o extender UML a un mtodo o proceso especfico, organizacin o usuario

20
UNIDAD DIDCTICA III: FUNDAMENTO DEL
DESARROLLO DEL DISEO ORIENTADO A
OBJETO
Elaboracin de diagramas, Diagrama de caso de Uso.
El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con
el sistema en desarrollo, adems de la forma, tipo y orden en como los elementos inter-
actan (operaciones o casos de uso).
Un diagrama de casos de uso consta de los siguientes elementos:
Actor.
Casos de Uso.
Relaciones de Uso, Herencia y Comunicacin.
Elementos
Actor: una definicin previa, es que un Actor es un rol que un usuario juega con
respecto al sistema. Es importante destacar el uso de la palabra rol, pues con
esto se especifica que un Actor no necesariamente representa a una persona
en particular, sino ms bien la labor que realiza frente al sistema.
Como ejemplo a la definicin anterior, tenemos el caso de un sistema de ventas
en que el rol de Vendedor con respecto al sistema puede ser realizado por un
Vendedor o bien por el Jefe de Local
Caso de Uso: es una operacin/tarea especfica que se realiza tras una orden
de algn agente externo, sea desde una peticin de un actor o bien desde la
invocacin desde otro caso de uso.

Relaciones:
Asociacin.- Es el tipo de relacin ms bsica que indica la invocacin
desde un actor o caso de uso a otra operacin (caso de uso). Dicha relacin se denota
con una flecha simple.
Dependencia o Instanciacin.- Es una forma muy particular de relacin
entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha
relacin se denota con una flecha punteada.
Generalizacin.- Este tipo de relacin es uno de los ms utilizados, cumple
una doble funcin dependiendo de su estereotipo, que puede ser de Uso (<<include>>)
o de Herencia (<<extends>>).

Este tipo de relacin est orientado exclusivamente para casos de uso (y no para
actores).
extends: se recomienda utilizar cuando un caso de uso es similar a otro
(caractersticas).
include: se recomienda utilizar cuando se tiene un conjunto de caractersticas que
son similares en ms de un caso de uso y no se desea mantener copiada la
descripcin de la caracterstica.
De lo anterior cabe mencionar que tiene el mismo paradigma en diseo y modelamiento
de clases, en donde est la duda clsica de usar o heredar.

21
Ejemplo: el caso de una mquina recicladora:
sistema que controla una mquina de reciclamiento de botellas, tarros y jabas. El
sistema debe controlar y/o aceptar:
Registrar el nmero de tems ingresados.
Imprimir un recibo cuando el usuario lo solicita:
a. Describe lo depositado
b. El valor de cada tem
c. Total
El usuario/cliente presiona el botn de comienzo
Existe un operador que desea saber lo siguiente:
a. Cuantos tems han sido retornados en el da.
b. Al final de cada da el operador solicita un resumen de todo lo depositado en el
da.
El operador debe adems poder cambiar:
a. Informacin asociada a tems.
b. Dar una alarma en el caso de que:
i. tem se atora.
ii. No hay ms papel.

Como una primera aproximacin identificamos a los actores que interactan con el
sistema:

Luego, tenemos que un Cliente puede Depositar tems y un Operador puede cambiar
la informacin de un tem o bien puede Imprimir un informe:

Adems podemos notar que un tem puede ser una Botella, un Tarro o una Jaba.

22
Otro aspecto es la impresin de comprobantes, que puede ser realizada despus de
depositar algn tem por un cliente o bien puede ser realizada a peticin de un operador.

Entonces, el diseo completo del diagrama Use Case es:

23
ESTEREOTIPOS Y RELACIONES EN LOS DIAGRAMAS.
Como veremos a continuacin, en los diagramas de casos de uso se muestran: casos
de uso (representados en forma de elipses), actores
(en forma de personajes) y relaciones (en forma de
lneas y/o flechas). UML define cuatro tipos de
relaciones en los diagramas de casos de uso:
Comunicacin: relacin (asociacin) entre un actor y
un caso de uso. El estereotipo de la relacin de
comunicacin es: <<communicate>> aunque
generalmente no se estipula ningn nombre, como
podemos apreciar en el siguiente ejemplo de comunicacin:
Inclusin: un caso de uso base incorpora explcitamente el comportamiento de otro en
algn lugar de su secuencia. La relacin de inclusin sirve para enriquecer un caso de
uso con otro y compartir una funcionalidad comn entre varios casos de uso, tambin
puede utilizarse para estructurar un caso de uso describiendo sus sub funciones. El caso
de uso incluido existe nicamente con ese propsito, ya que no responde a un objetivo
de un actor. Estas relaciones se representan mediante una flecha discontinua con el
estereotipo <<include>>. Algunos casos de uso tpicos de inclusin son: comprobar,
verificar, buscar, validar, autentificar o login En principio, no deberamos abusar de
este tipo de relacin, para no hacer una descomposicin funcional del sistema.

Extensin: un caso de uso base incorpora implcitamente el comportamiento de otro


caso de uso en el lugar especificado indirectamente por este otro caso de uso. En el
caso de uso base, la extensin se hace en una serie de puntos concretos y previstos en
el momento del diseo, llamados puntos de extensin, los cules no son parte del flujo
principal. La relacin de extensin sirve para modelar: la parte opcional del sistema, un
sub flujo que slo se ejecuta bajo ciertas condiciones o varios flujos que se pueden
insertar en un punto determinado. Este tipo de relacin produce confusin y no debera
utilizarse en exceso. Conviene su uso slo para insertar un nuevo comportamiento no
previsto en un caso de uso existente. Estas relaciones se representan mediante una
flecha discontinua con el estereotipo <<extend>>.

24
En este ejemplo usamos la relacin de extensin entre los casos de uso Abrir accin de
mejora y Resolver consulta. En este caso tendremos el punto de extensin resolucin
retrasada (en el caso de uso Resolver consulta) debido a que cuando haya pasado un
tiempo estipulado por la organizacin (por ejemplo 3 das laborales) se abrir una accin
de mejora para dejar constancia del retraso y realizar posteriormente las acciones
pertinentes, de ah que digamos que el caso de uso Abrir accin de mejora es una sub
funcin de uso que puede extender al caso de uso Resolver consulta.
Especializacin y generalizacin de los casos de uso: Un caso de uso (sub caso)
hereda el comportamiento y significado de otro, es decir las relaciones de comunicacin,
inclusin y extensin del sper caso de uso. En muchas ocasiones este sper caso de
uso es abstracto y corresponde a un comportamiento parcial completado en el sub caso
de uso. O dicho de otra manera, Los casos de uso hijo son una especializacin del
caso de uso padre. En la medida de lo posible debera evitarse puesto que produce
cierta confusin en algunas ocasiones.

25
DIAGRAMAS DE SECUENCIAS.
En un diagrama de secuencia indicarn
los mdulos o clases que forman parte
del programa y las llamadas que se
hacen en cada uno de ellos para realizar
una tarea determinada. Se realizan
diagramas de secuencia para definir
acciones que se pueden realizar en la
aplicacin en cuestin. As, en el caso de
una aplicacin para jugar al ajedrez, se
podran realizar diagramas de secuencia
para jugar una partida o bien para
acciones ms especficas como mover
pieza. El detalle que se muestre en el
diagrama de secuencia debe estar en
consonancia con lo que se intenta
mostrar o bien con la fase de desarrollo
en la que est el proyecto, no es lo mismo
un diagrama de secuencia que muestre la accin de mover pieza a otro que sea mover
caballo, o bien no es lo mismo un diagrama de secuencia mover pieza que verifique
ciertos parmetros antes de mover como la viabilidad del movimiento con respecto a
una estrategia marcada a una diagrama que no muestre este nivel de detalle por estar
en una fase inicial de diseo del sistema.

DIAGRAMA DE COLABORACIN.
El diagrama de colaboracin presenta una alternativa al diagrama de secuencia para
modelar interacciones entre objetos en el sistema. Mientras que el diagrama de
secuencia se centra en la secuencia cronolgica del escenario que estamos modelando,
el diagrama de colaboracin se centra en estudiar todos los efectos de un objeto dado
durante un escenario. Los objetos se conectan por medio de enlaces, cada enlace
representa una instancia de una asociacin entre las clases implicadas. El enlace
muestra los mensajes enviados entre los objetos, el tipo de mensaje (sincrnico,
asincrnico, simple, blanking, y 'time-out'), y la visibilidad de un objeto con respecto a
los otros.

26
UNIDAD DIDCTICA IV: DESARROLLO DE
DIAGRAMAS ORIENTADO A OBJETOS
DIAGRAMA DE CLASES Y OBJETOS
Un diagrama de clases sirve para visualizar las relaciones entre las clases que involu-
cran el sistema, las cuales pueden ser asociativas, de herencia, de uso 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.
Elementos
Clase.- Es la unidad bsica que encapsula toda la informacin de un objeto (un objeto
es una instancia de una clase). A travs de ella podemos modelar el entorno en estudio
(una Casa, un auto, una cuenta corriente, etc.).
En UML, una clase es representada por un rectngulo que posee tres divisiones:
Superior: contiene el nombre de la Clase
Intermedio: contiene los atributos (o variables de instan-
cia) que caracterizan a la Clase (pueden ser private, pro-
tected o public).
Inferior: contiene los mtodos u operaciones, los cuales
son la forma como interacta el objeto con su entorno
(dependiendo de la visibilidad: private, protected o pu-
blic).

Ejemplo:
Una Cuenta Corriente que posee como caracters-
tica:
Balance
Puede realizar las operaciones de:
Depositar
Girar
y Balance

Atributos y Mtodos:
Atributos: los atributos o caractersticas de una clase pueden ser de tres tipos, los que
definen el grado de comunicacin y visibilidad de ellos con el entorno, estos son:
public (+, ): indica que el atributo ser visible tanto dentro como fuera de la
clase, es decir, es accesible desde todos lados
private (-, ): indica que el atributo slo ser accesible desde dentro de la clase
(slo sus mtodos lo pueden acensar).
protected (#, ): indica que el atributo no ser accesible desde fuera de la clase,
pero si podr ser acezado por mtodos de la clase adems de las subclases
que se deriven (ver herencia).

27
Mtodos: los mtodos u operaciones de una clase son la forma en como sta interacta
con su entorno, stos pueden tener las caractersticas:
public (+, ): indica que el mtodo ser visible tanto dentro como fuera de la
clase, es decir, es accesible desde todos lados.
private (-, ): indica que el mtodo slo ser accesible desde dentro de la clase
(slo otros mtodos de la clase lo pueden acezar)
protected (#, ): indica que el mtodo no ser accesible desde fuera de la clase,
pero si podr ser acezado por mtodos de la clase adems de mtodos de las
subclases que se deriven (ver herencia).
Relaciones entre Clases:
Ahora ya definido el concepto de clase, es necesario explicar cmo se pueden interre-
lacionar dos o ms clases (cada uno con caractersticas y objetivos diferentes).
Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la car-
dinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada
extremo de la relacin y stas pueden ser:
uno o muchos: 1..* (1..n)
0 o muchos: 0..* (0..n)
nmero fijo: m (m denota el nmero).

Herencia (Especializacin/Generalizacin): Indica que una subclase


hereda los mtodos y atributos especificados por una Sper Clase, por ende la Subclase
adems de poseer sus propios mtodos y atributos, poseer
las caractersticas y atributos visibles de la Sper Clase
(public y protected), ejemplo:
Aqu se especifica que Auto y Camin heredan de Vehculo,
es decir, Auto posee las Caractersticas de Vehculo (Precio,
VelMax, etc.) adems posee algo particular que es
Descapotable, en cambio Camin tambin hereda las
caractersticas de Vehculo (Precio, VelMax, etc.) pero posee
como particularidad propia Acoplado, Tara y Carga.
Cabe destacar que fuera de este entorno, lo nico "visible" es
el mtodo Caractersticas aplicable a instancias de Vehculo,
Auto y Camin, pues tiene definicin pblica, en cambio
atributos como Descapotable no son visibles por ser privados.

Agregacin: para modelar objetos complejos, n bastan los tipos de datos


bsicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando
se requiere componer objetos que son instancias de clases definidas por el desarrollador
de la aplicacin, tenemos dos posibilidades:
Por Valor: es un tipo de relacin esttica, en donde el tiempo de vida del objeto
incluido est condicionado por el tiempo de vida del que lo incluye. Este tipo de
relacin es comnmente llamada Composicin (el Objeto base se construye a partir
del objeto incluido, es decir, es "parte/todo").

28
Por Referencia: es un tipo de relacin dinmica, en donde el tiempo de vida del
objeto incluido es independiente del que lo incluye. Este tipo de relacin es
comnmente llamada Agregacin (el objeto base utiliza al incluido para su
funcionamiento).
Un Almacn posee Clientes y Cuentas (los
rombos van en el objeto que posee las
referencias).
Cuando se destruye el Objeto Almacn tambin
son destruidos los objetos Cuenta asociados, en
cambio no son afectados los objetos Cliente
asociados.
La composicin (por Valor) se destaca por un
rombo relleno.
La agregacin (por Referencia) se destaca por
un rombo transparente.
La flecha en este tipo de relacin indica la navegabilidad del objeto referenciado.
Cuando no existe este tipo de particularidad la flecha se elimina.

Asociacin: La relacin entre clases conocida como Asociacin, permite


asociar objetos que colaboran entre s. Cabe destacar que no es una relacin fuerte, es
decir, el tiempo de vida de un objeto no depende del otro.
Un cliente puede tener asociadas
muchas rdenes de Compra, en
cambio una orden de compra solo
puede tener asociado un cliente.
Dependencia o Instanciacin (uso): representa un tipo de relacin muy particular, en
la que una clase es instanciada (su instanciacin es dependiente de otro objeto/clase).
Se denota por una flecha punteada. El uso ms particular de este tipo de relacin es
para denotar la dependencia que tiene una clase de otra, como por ejemplo una
aplicacin grafica que instancia una ventana (la creacin del Objeto Ventana est
condicionado a la instanciacin proveniente desde el objeto Aplicacin):
Cabe destacar que el objeto creado (en este caso la
Ventana grfica) no se almacena dentro del objeto que
lo crea (en este caso la Aplicacin)

Casos Particulares:
Clase Abstracta:
Una clase abstracta se denota con el
nombre de la clase y de los mtodos con
letra "itlica". Esto indica que la clase
definida no puede ser instanciada pues
posee mtodos abstractos (an no han

29
sido definidos, es decir, sin
implementacin). La nica forma de
utilizarla es definiendo subclases, que
implementan los mtodos abstractos
definidos.
Clase parametrizada: Una clase
parametrizada se denota con un
subcuadro en el extremo superior de la
clase, en donde se especifican los
parmetros que deben ser pasados a la
clase para que esta pueda ser instanciada.

El ejemplo ms tpico es el caso de un Diccionario en donde una llave o palabra tiene


asociado un significado, pero en este caso las llaves y elementos pueden ser genricos.
La generalidad puede venir dada de un
Template (como en el caso de C++) o
bien de alguna estructura predefinida
(especializacin a travs de clases). En
el ejemplo no se especificaron los
atributos del Diccionario, pues ellos
dependern exclusivamente de la
implementacin que se le quiera dar.
Supongamos que tenemos un el caso
del Diccionario implementado mediante
un rbol binario, en donde cada nodo posee:
key: variable por la cual se realiza la bsqueda, puede ser genrica.
tem: contenido a almacenar en el diccionario asociado a "key", cuyo tipo tambin
puede ser genrico.
Para este caso particular hemos definido un Diccionario para almacenar String y
Personas, las cuales pueden funcionar como llaves o como tem, solo se mostrarn las
relaciones para la implementacin del Diccionario

DIAGRAMA DE ESTADO, DIAGRAMAS DE ACTIVIDADES


En UML, un diagrama de estados es un diagrama utilizado
para identificar cada una de las rutas o caminos que puede
tomar un flujo de informacin luego de ejecutarse cada
proceso. Permite identificar bajo qu argumentos se ejecuta
cada uno de los procesos y en qu momento podran tener
una variacin. El diagrama de estados permite visualizar de
una forma secuencial la ejecucin de cada uno de los
procesos. Los diagramas de estado describen grficamente
los eventos y los estados de los objetos. Los diagramas de
estado son tiles, entre otras cosas, para indicar los eventos
del sistema en los casos de uso.

30
Un evento es un acontecimiento importante a tomar en cuenta para el sistema. Un
estado es la condicin de un objeto en un momento determinado: el tiempo que
transcurre entre eventos. Una transicin es una relacin entre dos estados, e indica que,
cuando ocurre un evento, el objeto pasa del estado anterior al siguiente.
Simbologa

Rectngulo de vrtices redondeados que representa a un


estado, junto con una lnea continua y una punta de flecha, que
representa una transicin.

Adicin de detalles al icono de estado.- El UML le da opcin de


agregar detalles a la simbologa. As cmo es posible dividir un
smbolo de clase en tres reas (nombre, atributo y
operaciones).

Ejemplo de
variables con
actividades:

Sucesos y acciones
El suceso provoca
una transicin y la
actividad se ejecuta
para que se
produzca la
transicin.

Por qu son importantes los diagramas de estados?


El diagrama de estados proporciona una gran cantidad de smbolos y abarca varias
ideas. Los desarrolladores, deben saber la forma en que los objetos se supone se
comportarn, ya que son ellos quienes tendrn que establecer tales comportamientos
en el software. Los diagramas de estado se aseguran que no tendrn que adivinar lo
que se supone que harn los objetos, con una clara representacin de un objeto
aumenta la probabilidad de que el equipo de desarrollo produzca un sistema que cumpla
con los requerimientos.

31
LOS DIAGRAMAS DE ACTIVIDADES
Sirven para representar el comportamiento dinmico de un sistema haciendo hincapi
en la secuencia de
actividades que se llevan a
cabo y las condiciones que
guardan o disparan esas
actividades
Elementos bsicos

DIAGRAMA DE COMPONENTES, INTERFACES.


Un Diagrama de Componente es, un esquema o diagrama que muestra las
interacciones y relaciones de los componentes de un modelo. Entendindose como
componente a una clase de uso especfico, que puede ser implementada desde un
entorno de desarrollo, ya sea de cdigo binario, fuente o ejecutable; dichos
componentes poseen tipo, que indican si pueden ser tiles en tiempo de compilacin,
enlace y ejecucin.

32
Tipos De Diagramas De Componentes
Los Diagramas de Componentes se pueden clasificar en tres categoras:
Componentes de despliegue: necesarios y suficientes para formar un sistema
ejecuta. Por ejemplo: bibliotecas dinmicas (dll), ejecutables (exe).
Componentes productos de trabajo: surgen durante el proceso de desarrollo y
queda al final del mismo. Por ejemplo: buscarCliente.jar, cliente.db.
Componentes de ejecucin: se crean como consecuencia de un sistema de
ejecucin Por ejemplo: objetos que se instancian a partir de una dll.
Porqu se diferencian?
Un componente representa un elemento fsico (bits).
Una clase es una abstraccin lgica.
El componente se puede representar en nodos fsicos, la clase no.
Las operaciones de un componente solo se alcanzan a travs de interfaces. Las de
una clase podran ser accesibles directamente.

Una interfaz contiene una coleccin de operaciones y se utiliza para especificar los
servicios de una clase o de un componente. Una interfaz se conecta al componente que
la implementa a travs de una relacin de realizacin, y al componente que utiliza sus
servicios con una dependencia.

Componentes e Interfaces
Interfaz de exportacin: interfaz realizada por un componente, servicio que
ofrece a otros componentes.
Interfaz de Importacin: interfaz usada por un componente.
La ventaja de usar interfaces es que se rompe la dependencia directa entre
componentes. Un componente que usa una interfaz puede funcionar adecuadamente
independientemente del componente que la realiza.

Caractersticas de un Componente.-
Un componente es fsico existe en el mundo de los bits.
Un componente es reemplazable es posible reemplazar un componente por otro
que conforme con las mimas interfaces.
Un componente es una parte de un sistema representa un bloque de
construccin fundamental sobre el cual se puede disear y construir sistemas.
Un sistema puede ser solo un componente en un nivel de abstraccin mayor,
compuesto por componentes.

33
Tipos de Componentes
Componentes de despliegue: necesarios y suficientes
para formar un sistema ejecutable. Por ejemplo:
bibliotecas dinmicas (dll), ejecutables (exe).
Componentes productos de trabajo: surgen durante el
proceso de desarrollo y quedan al final del mismo. Por
ejemplo: buscarCliente.jar, cliente.db.
Componentes de ejecucin: se crean como consecuencia de un sistema en
ejecucin. Por ejemplo: objetos que se instancian a partir de una dll.

Estereotipos Estndar de Componentes


executable: especifica un componente ejecutable en
un nodo.
library: especifica una biblioteca de objetos.
table: especifica una tabla de una BD.
file: especifica un componente que contiene un
documento con cdigo fuente o datos.
document: especifica un componente que representa
un documento.
NODO.- Es un elemento fsico que existe en tiempo de
ejecucin y representa un recurso computacional, que
generalmente tiene alguna memoria y capacidad de
procesamiento. Posee un nombre simple, ej.: Ventas o un
nombre extendido indicando el paquete que lo contiene, ej.:
servidor:: Ventas.

La relacin entre un nodo y un componente se puede


modelar con una relacin de dependencia.
Los nodos se pueden organizar agrupndolos en paquetes.
Tambin a travs de relaciones de dependencia,
generalizacin, asociacin, agregacin. Generalmente se
conectan con una asociacin.

DIAGRAMA DE DESPLIEGUE.
Modela aspectos fsicos de un sistema.
Modela la vista de despliegue esttica de un sistema.
Modela una configuracin de nodos y los componentes que residen en ellos.
Modela la topologa del hardware donde se ejecuta el sistema.
Los elementos que lo componen son:
Nodos
Relaciones de dependencia, generalizacin, asociacin y realizacin.
Pueden contener los componentes que residen en los nodos.

34
Trabajo de Investigacin
1. Realizar el modelado de un pequeo comercio como una tienda de venta
de calzado, incluir los mximos modelos en este pequeo trabajo.

Fuentes de Informacin
http://es.wikipedia.org/wiki/Sistema_de_informaci%C3%B3n_gerencial
http://www.monografias.com/trabajos94/sistema-informacion-gerencial-
estrategico/sistema-informacion-gerencial-estrategico.shtml
http://www.monografias.com/trabajos94/analisis-y-diseno-sistemas-
informacion/analisis-y-diseno-sistemas-informacion.shtml
http://eii.ucv.cl/pers/guidi/cursos/estructuras/pdf/SE-DiagramasDeClasesUML.pdf
http://www.altova.com/es/umodel/class-diagrams.html
http://es.wikipedia.org/wiki/Diagrama_de_clases
http://www.codecompiling.net/files/slides/UML_clase_03_UML_actividades_estados.pdf
http://www.slideshare.net/juliopari/sesion-7-3-diseo-diagramas-de-componentes
http://es.wikipedia.org/wiki/Diagrama_de_estado
http://www.slideshare.net/EstefanyAlanoca/tutorial-de-diagramas-de-estado
http://www.slideshare.net/TerryJoss/diagrama-de-actividades-6096986
http://es.wikipedia.org/wiki/Diagrama_de_componentes
http://www.monografias.com/trabajos67/diagramas-uml/diagramas-uml.shtml
http://es.wikipedia.org/wiki/Diagrama_de_despliegue
http://www.slideshare.net/albertozurita96/diagrama-de-despliegue-17071673

35

También podría gustarte