DIRECCION DE ESTUDIOS VIRTUALES
LIC. INFORMACION Y DOCUMENTACION
VIII Trimestre – Análisis y Diseño de Sistemas
Prof.: Yaros Pérez Participante: Mirlena Malavé
ANALISIS
Y DISEÑO DE SISTEMAS
Un sistema o “grupo de elementos interdependientes o que interactúan
regularmente formando un todo”, puede
incluir o no computadoras, más sin embargo, la labor primordial del análisis y
diseño es la de estudiarlo para determinar su esencia, modelar su
comportamiento e implantarlo.
Entre sus objetivos tenemos:
a.- Eficiencia: Se busca diseños que hagan un uso inteligente de los
recursos.
b.- Confiabilidad: La confiabilidad
del software puede ser vista como un problema de depuración de errores en los programas, pero es
también un
problema de diseño.
La confiabilidad se expresa como MTBF (mean time between fairules: tiempo medio
entre fallas).
c.- Mantenibilidad: Un sistema es
mantenible si permite la detección,
análisis,
rediseño, y
corrección de
errores fácilmente.
d.- Modificabilidad: Es la
posibilidad de realizar modificaciones y extensiones a partes del sistema, o
agregar nuevas partes con facilidad (no corrección de errores).
e.- Flexibilidad: Representa la facilidad
de que el mismo sistema pueda realizar variaciones sobre una misma temática, sin necesidad de modificaciones.
f.- Generalidad: Expresa el alcance sobre
un determinado tema.
g.- Utilidad o facilidad de uso: Es
un factor importante que influye en el éxito
del sistema y su aceptación
por parte del usuario.
h.- Costo mínimo: Obtener
sistemas económicos
para desarrollar, operar, mantener y modificar.
Dentro
de un proyecto de desarrollo de sistemas automatizado participan: los
usuarios (para quien se construye), administradores (de recursos, de
personal), auditores (asegurar
que su sistema se desarrolle de acuerdo con diversos estándares o normas
externas), analistas (personaje clave
en cualquier proyecto de desarrollo de sistemas e interactúa con los demás
participantes realiza una descripción no técnica de los requerimientos del
sistema), diseñadores (realiza una
descripción arquitectónica del hardware y software que se usará para poner en
practica al sistema), programadores
(realiza la labor de programación del sistema), personal de operaciones (quienes reciben el sistema luego de que
este ha sido analizado, diseñado, programado y probado el sistema, responsables
de la red de comunicaciones, centro de cómputos, seguridad de hardware y
software, etc.).
I.-
ANALISIS Y DISEÑO ESTRUCTURADO:
La actividad de Análisis parte de los requerimientos observados
durante el proceso de estudio del dominio
del problema y arroja como resultado lo QUE debe hacer el sistema para
brindar una solución al
problema del usuario, independientemente de la naturaleza de la tecnología que se use para su implementación. El análisis transforma las políticas del usuario y el esquema del
proyecto en una especificación
estructurada.
Los Modelos del Análisis
El Modelo Esencial de Análisis estructurado consta de:
a.- Lista de Acontecimientos que a la misma vez,
consta de declaración de propósitos, modelo ambiental y un diagrama de
contexto.
b.- Modelo de Comportamiento que consta de un
modelo preliminar y un modelo terminado.
La actividad de Diseño se dedica a asignar porciones de la especificación estructurada resultante del proceso
de análisis
(también
conocida como modelo esencial) a procesadores adecuados (sean máquinas o humanos), y a labores apropiadas
(tareas, particiones, etc.) dentro de cada procesador. Dentro de cada labor, la
actividad de diseño
se dedica a la creación
de una jerarquía
apropiada de módulos
de programas y de interfaces entre ellos, para implantar la especificación creada durante el análisis. Además la actividad del diseño se ocupa de la transformación del modelo de datos de
entidad-relación en
un diseño de
base de datos.
En el Diseño estructurado se debe
definir: ¿Qué es?, para qué? Aquí se toma en cuenta la
ingeniería del software menos costo, más calidad. Cómo?
Establecer los objetivos, principios, restricciones, estrategias y metodologías,
dividiendo el todo en partes. Modelos: Programas, datos y de interfaces.
I.1.- Principios:
a.- Abstracción: Permite
concentrarse en un problema al mismo nivel de generalización, independientemente de los detalles
irrelevantes de bajo nivel. La
abstracción es el examen selectivo de ciertos aspectos de un
problema.
b.- Refinamiento sucesivo: Se desarrolla una jerarquía descomponiendo una declaración macroscópica de una función de una forma sucesiva, hasta que se
llega a las sentencias del lenguaje de programación.
c.- Modularidad: El software se divide en componentes
con nombres y ubicaciones determinados, que se denominan módulos, y que se integran para satisfacer
los requisitos del problema.
d.- Arquitectura del software: Se refiere a las características más importantes del software de
computadoras: la estructura jerárquica
de los componentes procedimentales (módulos)
y a la estructura de datos
e.- Jerarquía de
control: También denominada estructura de programa, representa la organización (frecuentemente jerárquica) de los componentes del
programa (módulos)
e implica una jerarquía
de control.
f.- Estructura de datos: Es una
representación de
la relación lógica existente entre los elementos
individuales de datos.
g.- Procedimientos del software: Se centra sobre los detalles de
procesamiento de cada módulo
individual.
h.- Ocultamiento de la información: Sugiere
que los módulos
se han de caracterizar por decisiones de diseño que los oculten unos a otros.
1.2- Criterios
de Validación de Calidad:
a.- Acoplamiento entre módulos clasifica el grado de
independencia entre pares de módulos de un Diseño Estructurado. El objetivo es
minimizar el acoplamiento, es decir, maximizar la independencia entre módulos.
b.- Cohesión: Cómo las actividades de un módulo están relacionadas
unas con otras; es la medida de intensidad de asociación funcional de los
elementos de un módulo.
c.- Descomposición: Es la separación de una función contenida en
un módulo, para un nuevo módulo.
d.- Fan-Out: Es usado como una medida de
complejidad. Es el número de
subordinados inmediatos de un módulo (cantidad de módulos invocados).
e.- Fan-In: Es
usado como una medida de reusabilidad,
es el número de superiores inmediatos de un módulo (la cantidad de módulos que
lo invocan).
1.3.- Ventajas y Desventajas:
La programación modular
presenta innumerables ventajas. En primer lugar, al permitir la descomposición
del programa en trozos de tamaño manejable hace más fácil de escribir y probar
el programa, y hace el proceso de dirección más sencillo. Asimismo, la
estructura de los módulos facilita el ocultamiento de información ya que se
pueden especificar los detalles internos por un lado, y la parte visible por
otro.
La programación
modular facilita la abstracción, ya que se puede describir el sistema con
varios niveles de abstracción, de forma jerárquica, con módulos compuestos a su
vez por otros módulos. Si el programa es modular, su modificación es más
sencilla, ya que la independencia entre los módulos facilita el que un cambio
en un módulo no afecte al resto. Además, el programa es más fácil de probar, ya
que podemos hacer las pruebas de cada módulo por separado, y luego realizar la
prueba del programa conjunto separadamente (prueba de integración). De esta
forma es mucho más fácil localizar y corregir los errores, la hacerse la prueba
paso a paso.
Sin embargo, la
programación modular requiere esfuerzo y cuidado en el diseño, para hacer los
módulos independientes. Si los módulos no son independientes no se consigue una
verdadera programación modular.
II.- ANALISIS Y DISEÑO ORIENTADO A
OBJETOS:
Desde principio de los años 80 se han
venido generalizando los métodos orientados a objeto tanto para el análisis y
diseño, como para la codificación de programas. El método hace el software más
fácil de entender, al existir una relación directa entre su estructura y la del
sistema o problema a resolver.
En un sistema
orientado a objetos los objetos que tienen las mismas características se
agrupan en las llamadas clases de objetos. En una metodología orientada al
objeto las clases de objetos o los objetos individuales suelen tener tres
componentes:
• nombre:
identifica al objeto o a la clase
• atributos:
existe un atributo por cada uno de los datos o valores que el objeto puede
almacenar; el conjunto de los valores de los atributos de un objeto determina
su estado
• operaciones:
cada objeto tiene un conjunto de operaciones que se pueden invocar desde el
exterior; al invocarse una operación se le pueden pasar parámetros (datos de
entrada o salida) al objeto; la ejecución de la operación normalmente implica
el cambio de los atributos y, posiblemente, la invocación de
operaciones de otros objetos.
Si el análisis
del sistema es un análisis orientado a objeto, lo lógico es hacer el diseño
también mediante una metodología orientada al objeto. En el análisis se
realizan las siguientes actividades:
• organizar el sistema en subsistemas
• identificar la concurrencia entre objetos
• asociar objetos a recursos (por ejemplo a
procesadores)
• elegir la estrategia de almacenamiento de
información (ficheros, sistemas distribuidos, datos en memoria, etc.)
• elegir la estrategia de implementación,
que puede ser una máquina de estados abstracta, tareas concurrentes, etc.
• considerar los aspectos del entorno
• establecer prioridades
En el diseño detallado lo que se
pretende es una definición detallada de cada objeto. Generalmente se hacen
diagramas más detallados que en el análisis tanto para los objetos, como para
su comportamiento dinámico y funcional. Para cada objeto se eligen los
algoritmos para sus operaciones, las representaciones concretas de cada
atributo, y la forma de implementar las diferentes relaciones entre los
objetos.
II.1.- Principios:
a.- Encapsulamiento: El empaque
conjunto de datos y métodos se llama encapsulado. El objeto esconde sus datos
de los demás objetos y permite el acceso a los datos mediante sus propios
métodos. Esto recibe el nombre de ocultamiento de información. Evita la
corrupción de los datos de un objeto.
b.- Herencia: Una clase implanta el tipo de
objeto. Una subclase hereda propiedades de su clase padre; una sub-subclase
hereda propiedades de las subclases; etc. Una subclase puede heredar la
estructura de datos y los métodos, o algunos de los métodos, de su superclase.
También tiene sus métodos e incluso tipos de datos propios.
c.- Polimorfismo: Se aplica a una operación que
adopta varias formas de implantación según el tipo de objeto, pero cumple
siempre el mismo objetivo.
II.2.- Ventajas y Desventajas:
|
VENTAJAS |
DESVENTAJAS |
|
·
Alta curva de aprendizaje ·
Costosa ·
Requiere conocimientos adicionales ·
No recomendable para proyectos pequeños ·
Requiere personal especializado |
II.3.- Conceptos Básicos:
a.- Objeto:
Dentro del software orientado a objeto, un objeto es cualquier cosa, real o
abstracta, acerca de la cual almacenamos datos y los métodos que controlan
dichos datos. Un objeto puede estar compuesto por otros objetos y estos a su
vez también pueden estar compuestos por otros objetos.
b.-
Entidad: Sólo se refiere a datos.
c.-
Método: Especifican la forma en que se controlan los datos de un objeto.
d.- Mensaje: Es una solicitud para que se lleve a
cabo la operación indicada y se produzca el resultado.
e.- Clases: Es una implantación de un tipo de
objeto. Especifica una estructura de datos y los métodos operativos permisibles
que se aplican a cada uno de sus objetos.
f.- Evento: Aquel que produce un cambio en el
estado del objeto.
g.- Operación: se refiere a una unidad de
procesamiento que puede ser solicitada.
III.- DIFERENCIAS
ENTRE DISEÑO ESTRUCTURADO Y ORIENTADO A OBJETO:
a.- El diseño modular es una técnica que viene usándose desde hace mucho
tiempo. El problema es cómo partir en módulos independientes. Antes solía
hacerse de acuerdo a criterios funcionales (agrupar funciones similares)
Inconvenientes:
• Cada figura -
objeto del espacio problema - reside en varios módulos de programa (por tanto
estos módulos no son independientes)
• Un cambio en el objeto
del espacio problema implica cambiar muchos módulos, y volverlos a probar
• Añadir nueva
funcionalidad implica normalmente tocar varios módulos, y volverlos a probar
(por ejemplo, añadir una figura nueva).
• En definitiva, el
software es difícil de cambiar o extender y poco reutilizable
b.- En el Diseño orientado a objeto, se puede utilizar otra aproximación a
la partición en módulos:
• división orientada
a objetos
• cada objeto del
problema real que es preciso resolver, es un módulo del programa
• se encapsulan
juntas la definición del objeto y todas sus operaciones
El diseño de programas
orientado a objetos pretende:
• simplificar la
modificación y extensión del software, haciendo que la mayor parte del mismo
sea reutilizable
• es más fácil de
entender ya que existe relación directa entre la estructura del software y la
del problema, en muchos casos, extender
la funcionalidad no implica modificar el software existente, sino sólo añadir
nuevos objetos
• el cambio interno
en un objeto afecta a un solo módulo.
IV.- EJEMPLO
PRACTICO.-
El desarrollo de una aplicación web
simple, siguiendo la
metodología orientada a objeto, facilita el traslado del diseño conceptual a la
implementación, proveyendo herramientas que permiten reducir la distancia entre
el problema del mundo real y la programación de la solución en la computadora.
a.-
Capa Conceptual:
El modelo de objetos de este ejemplo
consta de las entidades básicas de un dominio específico: un comercio de venta
de productos B2C (Negocio a Consumidor). En este dominio, entidades como producto, categoría de
productos, carro
de compras, usuario, venta, se interrelacionan para responder a
la navegación del usuario por la aplicación y a sus actividades
transaccionales. Todas las entidades mencionadas se construyen a partir de
información persistente, propiedad mantenida por la empresa en forma directa a
través de un DBA (Administrador de Bases de Datos) o simplemente aprovechando
una funcionalidad incorporada de la aplicación que permita manipular la base de
datos.
En cada diseño conceptual existe
comportamiento que escapa a la simple navegación de información. Se trata del
comportamiento inherente de cada clase, y aunque la aplicación particular no
requiera que se implemente, es importante destacar que si la aplicación crece
el diseño conceptual debe estar preparado para ser extendido, tal como
cualquier diseño orientado a objetos. Retomando el diseño conceptual, el
análisis anterior de las entidades del dominio permite afirmar que dichas
clases comparten (al menos) el comportamiento correspondiente a la interfaz con
la capa de persistencia. Las clases del
diseño conceptual que representen a estas entidades podrán obtener sus
atributos al iniciarse y actualizar los cambios cuando sea necesario
(realizando eventualmente algún tipo de almacenamiento temporal para mejorar la
eficiencia). La consistencia de la información queda asegurada, entonces, por
el comportamiento de los objetos del modelo. El lenguaje elegido para
desarrollar la implementación de esta capa es Java (lenguaje de programación orientado a
objetos desarrollado por la compañía Sun Microsystems y que fue diseñado para
que la ejecución de código a través de la red fuera segura). Durante esta etapa
se utilizará como paquete de vital importancia para el manejo de base de datos
el JDBC (Conectividad de Base de Datos. Es una interfaz que provee comunicación
con bases de datos. Consiste de un conjunto de clases e interfaces escritas en Java, que proveen una API -Interfaz de
Programación de Aplicación- estándar para desarrolladores de herramientas de
base de datos, permitiendo independizar la aplicación de la base de datos que
utiliza).
La clase abstracta que define el
comportamiento básico de las entidades del modelo y concentra la lógica de
interacción con la base de datos será denominada Entidad
Abstracta. Para
cumplir con los objetivos propuestos, esta clase debe ser capaz de crear una
conexión con la base de datos, ejecutar consultas y retornar los resultados
para ser procesados. Sólo la información más
importante y de menor volumen es cargada desde la base de datos en el momento
de la instanciación. La información restante puede ser cargada bajo demanda, a
partir de un eventual requerimiento de la aplicación. Para ilustrar esta idea
con claridad puede considerarse cargar los siguientes atributos en la
instanciación de un Producto: descripción, categoría,
cantidad disponible y precio. En algún momento de la ejecución, la aplicación
puede requerir los productos relacionados de un determinado producto (por
ejemplo, el usuario podría solicitar una lista de productos relacionados con el
producto televisor, tales como video grabadora, filmadora, mesa para televisor,
etc.); dado el volumen de esta información y lo esporádico de su requerimiento,
se sugiere entonces consultar a la base de datos para obtener esta información
sólo cuando es requerida.
b.- Capa Navegacional:
La capa navegacional se compone de
objetos construidos a partir de objetos conceptuales, y constituyen en general
los elementos canónicos de las aplicaciones hipermedia tradicionales: nodos, enlaces, anclas y estructuras
de acceso. Sin
embargo, estas clases pueden extender el comportamiento característico para
funcionar como adaptadores de los objetos conceptuales y delegar
así operaciones específicas del dominio. Entonces, los objetos navegacionales
pueden actuar como observadores, para construir vistas de objetos
conceptuales, y como adaptadores, para extender la actividad
navegacional de un nodo y poder aprovechar el comportamiento conceptual del
objeto adaptado. Estas dos perspectivas pueden implementarse aprovechando las
virtudes inherentes de diferentes tecnologías: JSP (páginas de servidor java)
para observar y Servlets
(clase de Java utilizada para extender la capacidad del servidor) para adaptar.
Las páginas JSP serán responsables de
construir los nodos de la capa navegacional. Esto se logra instanciando los
objetos del diseño conceptual necesarios para mostrar la información del nodo y
utilizando los datos solicitados a dichas instancias para generar árboles de
elementos XML (formato de transferencia de datos multi-plataforma). Con este procedimiento se compone un nodo
concentrando información relacionada en un documento XML generado dinámicamente
con cada requerimiento, lo que permite además personalizar el contenido (datos
sin presentación) a partir de infinitas configuraciones, tales como un perfil
de usuario, la sobrecarga de requerimientos de la aplicación, la historia
registrada de la navegación, políticas de protección de contenidos, seguridad,
etc.
Para mostrar el contenido del carro de
compras del usuario es necesario instanciar el objeto conceptual CarroDeCompras
(notar que el
identificador del usuario que navega la aplicación y solicita acceder a su
carro de compras es el único dato que se necesita para invocar al constructor
de dicha entidad). De este modo, el nodo construido a partir de esta
información no sólo concentra los datos de las compras sino que además ofrece
un menú de operaciones para manipular el carro de compras, como borrar un
elemento, cambiar la cantidad solicitada de un producto, vaciar el carro,
finalizar la compra. Todas estas operaciones no son responsabilidad del nodo,
sino que son realizadas por el objeto conceptual. Entonces, delegar
responsabilidad es lo único que debe hacer el nodo navegacional en este caso:
la actividad delegada continúa dentro de un servlet y finalmente es el servlet
quien se encarga de
redireccionar la navegación a una página JSP para eventualmente mostrar un
resultado.
c.-
Capa de Interfaz Abstracta:
Tanto un nodo actuando como observador
como un nodo actuando como adaptador, finalmente continúa por mostrar cierta
información y para ello necesita definir la forma de presentación mediante la
cual dicha información será visualizada en la interfaz. Para ello se incorporan
las tecnologías XSL (lenguaje de hojas de estilo extensible) y un mecanismo de
análisis sintáctico para obtener una página HTML en función de un par de
documentos XML/XSL. Las páginas XSL, ubicadas también del lado del servidor,
definirán la apariencia de los nodos que se generaron en formato XML (lenguaje
de marcado extensible). Cada página XSL define la forma en que los elementos
del XML asociados serán mostrados, haciendo uso de código HTML y eventualmente
CSS [24], para dar el formato deseado a las páginas finales. En este caso, se
desea obtener un documento de salida con formato HTML a partir de un par de
documentos XML / XSL.
IV.- Infografía:
1.- Diseño Orientado a Objeto:
2.- Diagramas de Estructura:
La lógica de
cada diseñador se expresa en la confección del diagrama de estructura, por lo
tanto irán desde lo más secuenciales hasta los más estructurados; por lo tanto
no puedo decir que hay normas estrictas que indican una única forma de
realizarse lo importante es que lo mismos sean claros, consistentes y nos
representen realmente las rutas que seguirá luego nuestro código del sistema
mismo.
3.- Análisis Estructurado:
El análisis
estructurado permite al analista conocer un proceso (actividad) en una
forma lógica y manejable al mismo tiempo que proporciona la base para asegurar
que no se omite ningún detalle pertinente. Por otra parte una de
las claves del éxito de un buen análisis será el que exista una buena
comunicación entre usuarios y analistas, esto obliga a disponer de un lenguaje
común, sencillo y fiable de modo que permita minimizar costes y errores, y
maximizar la calidad.
4.- Ingeniería del Software:
El análisis estructurado se concentra
en especificar lo que se requiere que haga el sistema o la aplicación. Permite
que las personas observen los elementos lógicos (lo que hará el sistema)
separados de los componentes físicos (computadora, terminales, sistemas de almacenamiento, etc.). Después de esto se puede desarrollar un
diseño físico eficiente para la situación donde será utilizado.
http://www.monografias.com/trabajos5/inso/inso.shtml
5.- Análisis y Diseño
Permite al analista
conocer un sistema o proceso (actividad) en una forma lógica y manejable al
mismo tiempo que proporciona la base para asegurar que no se omite ningún
detalle pertinente. El objetivo que persigue el análisis estructurado es
organizar las tareas asociadas con la determinación de requerimientos para
obtener la comprensión completa y exacta de una situación dada.
http://www.monografias.com/trabajos10/andi/andi.shtml
6.- Programación Orientada a Objeto
http://es.wikipedia.org/wiki/Programación_orientada_a_objetos
7.- Análisis Estructurado
de Sistemas de Información
El desarrollo de un
sistema de información, independientemente de su tamaño y complejidad, requiere
muchas actividades coordinadas y el empleo de una diversidad de herramientas y
modelos. La metodología de desarrollo de sistemas es una forma estándar de
organizar y coordinar estas actividades. El análisis de sistemas llega a
la raíz del problema o a la necesidad y define los requerimientos de los
usuarios.
http://us.geocities.com/g
axiola_2000/sistemas/estructurado.html
8.- Análisis y Diseño Orientado a Objetos
Durante los últimos años
ha ido creciendo en forma considerable el análisis y diseño orientado a
objetos. Se han publicado numerosos libros y muchas organizaciones están listas
para implementar la práctica de esta nueva tecnología. De un tiempo para acá ha
venido presentándose un interés creciente en el campo del análisis orientado a
objetos (AOO) y el diseño orientado a objetos (DOO). Este interés es debido a
que la programación orientada a objetos (POO) se ha impuesto debido a sus
enormes ventajas, pero las metodologías de análisis y diseño tradicional no son
aplicables. Con la publicación de numerosos libros, los métodos se han
estabilizado y ahora las organizaciones pueden moverse con tranquilidad a esta
nueva tecnología.
http://www.inei.gob.pe/biblioineipub/bancopub/inf/Lib5040/TECN08.HTM
9.- Tecnología orientada a
objetos
Para el desarrollo de
software orientado a objetos no basta usar un lenguaje orientado a objetos.
También se necesitará realizar un análisis y diseño orientado a objetos. El
modelamiento visual es la clave para realizar el análisis OO. Desde los inicios
del desarrollo de software OO han existido diferentes metodologías para hacer
esto del modelamiento, pero sin lugar a duda, el Lenguaje de Modelamiento
Unificado (UML) puso fin a la guerra de metodologías.
http://java.ciberaula.com/articulo/tecnologia_orientada_objetos/