Cátedra
de ANÁLISIS Y DISEÑO DE SISTEMAS
Profesor YAROS
PÉREZ
TRABAJO 1
ANÁLISIS Y DISEÑO ESTRUCTURADO Y
ORIENTADO A OBJETOS.
Definición
Diferencias
caso práctico
REFERENCIAS
Definición
Análisis Estructurado
Se concentra en especificar
lo que se requiere que haga el sistema o la aplicación. No se establece como se
cumplirán los requerimientos o la forma que se implantará la aplicación. Permite
que las personas observen los elementos lógicos (lo que el sistema hará)
separados de los componentes físicos (computadoras, sistemas de almacenamiento,
etc.). Después de esto puede desarrollarse un diseño físico eficiente para la
situación donde será utilizado.
Los elementos esenciales
son del análisis estructurado: son símbolos gráficos, diagramas de flujo de
datos y diccionario centralizado de datos.
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.
Componentes:
- Símbolos gráficos: sirven para identificar y
describir los componentes de un sistema y las relaciones entre estos.
- Diccionarios de datos: Descripciones de todos los
datos utilizados en el sistema pueden ser manual o automatizado.
- Descripciones de procesos y procedimientos:
emplean técnicas y lenguajes que permiten describir actividades del
sistema.
- Reglas: Estándares par describir y documentar el
sistema en forma correcta y completa.
Análisis de flujo de
datos:
Estudia el empleo de los
datos en cada actividad, documenta los hallazgos con diagramas de flujo de
datos.
Herramientas:
- Diagrama de flujo de datos: son la herramienta
mas importante y la base en donde se desarrolla otros componentes
- Diccionario de datos: contienen las
características lógicas de los lugares donde se almacenan los datos del
sistema, incluyendo nombre, alias, descripción, contenido y organización.
- Diagrama de estructuras de datos: este es una
descripción de la relación entre entidades (personas, lugares, eventos y objetos ) y el conjunto de información relacionado con
la entidad.
- Gráfica de estructura: es la herramienta del
diseño que muestra con símbolos la relación entre los módulos de
procesamiento y el software de la comp.
Diseño Estructurado
Definición: "Diseño
estructurado es el proceso de decidir que componentes, y la interconexión entre
los mismos, para solucionar un problema bien especificado".
Se enfoca en el desarrollo
de especificaciones del software. La meta del diseño estructurado es crear
programas con módulos independientes unos de los otros desde el punto de vista
funcional.
Es una técnica específica
para el diseño de programas y no un método de diseño de compresión. Esta
técnica conduce a la especificación de módulos de programas que son
funcionalmente independientes.
La herramienta fundamental
del diseño estructurado es el diagrama estructurado, los cuales son de
naturaleza gráfica y evitan cualquier referencia relacionada con el hardware o
detalles físicos.
Su finalidad no es mostrar la lógica de los
programas. Los diagramas estructurados describen la interacción de los módulos
independientes, junto con los datos que un modulo pasa a otro cuando interactúa
con él.
Diferencias
Diferencias entre análisis y diseño
La mayoría de proyectos de software son complejos, y
la estrategia primaria para superar la complejidad, es la descomposición. La estrategia es
dividir el problema en unidades más pequeñas que sean manejables. Un enfoque tradicional para realizar esto fue el análisis y diseño estructurados,
donde se trata de descomponer el problema en funciones o procesos.
Unas forma de realizar la descomposición, es usando un
esquema de análisis y diseño orientado
a objetos. En este esquema, se busca descomponer el problema en objetos,
y no en funciones. Por ejemplo, una descomposición orientada a objetos del
Sistema de Información de Biblioteca podría ser la siguiente:
Algunas
de las tareas a realizarse en la etapa de análisis son las siguientes:
1. Definir los requerimientos.
2. Definir los casos esenciales de uso.
3. Crear y perfeccionar los diagramas de casos de uso.
4. Crear y perfeccionar el modelo conceptual.
5. Crear y perfeccionar el glosario.
6. Definir los diagramas de secuencia de los sistemas.
7. Definir los contratos de operaciones.
Algunas
de las tareas a realizarse en la etapa de diseño son las siguientes:
1. Definir los casos reales de uso.
2. Definir los reportes, la interfaz de usuario y la
secuencia de las pantallas.
3. Perfeccionar la arquitectura del sistema.
4. Definir los diagramas de interacción.
5. Definir los diagramas de diseño de clases.
6. Definir el esquema de la base de datos.
caso práctico
Un sistema orientado a objetos se
compone de objetos que envían mensajes a otros objetos para que lleven a cabo
ciertas operaciones. Cada clase de objetos tiene ciertas responsabilidades, que son cumplidas
a través de sus métodos, y por la forma en que colabora con las otras clases de
objetos.
Decisiones
poco acertadas sobre la asignación de responsabilidades de cada clase, dan
origen a sistemas y componentes frágiles y difíciles de mantener, entender,
reutilizar o extender.
Responsabilidades
Las
responsabilidades se relacionan con las obligaciones de un objeto respecto de
su comportamiento. Estas responsabilidades pertenecen, esencialmente, a dos
categorías: conocer y hacer. Entre las responsabilidades de
un objeto relacionadas con el hacer
se encuentran:
· Hacer algo en uno mismo.
· Iniciar una acción en otros objetos.
· Controlar y coordinar actividades en otros objetos.
Entre
las responsabilidades de un objeto relacionadas con el conocer se encuentran:
· Estar enterado de los datos privados encapsulados.
Estar enterado de la existencia de objetos
conexos.
· Estar enterado de cosas que se pueden derivar o
calcular.
Las responsabilidades se asignan a los objetos durante
el diseño orientado a objetos. Por ejemplo, podría decirse que una Venta es responsable de imprimirse
ella misma (un hacer), o que
una Venta tiene la obligación
de conocer su fecha (un conocer).
Responsabilidad no es lo mismo que método: los métodos
se usan para cumplir con las responsabilidades. Éstas se implementan usando
métodos que operen solos o en colaboración con otros métodos y objetos. Así por
ejemplo, la clase Venta podría
definir uno o varios métodos para imprimir una instancia Venta (por ejemplo el método imprimir). Para hacer esto, Venta puede colaborar con otros
objetos, por ejemplo, enviando mensajes a VentasLineadeProducto para que
se impriman ellos mismos.Los diseñadores expertos en
orientación a objetos, van formando un amplio repertorio de principios
generales que los guían al crear software. Estos principios son llamados patrones, y se codifican en un
formato estructurado que describe el problema y su solución. Cada patrón tiene
un nombre. Los patrones no se proponen descubrir ni expresar principios nuevos
en Ingeniería de Software. Todo lo contrario, intentan codificar el
conocimiento y los principios ya
existentes: cuanto más generalizados y usados, mejor.
El patrón Experto [Larman
98]
|
Nombre: |
Experto. |
|
|
Problema: |
¿Cuál
es el principio fundamental en virtud del cual se asignan las
responsabilidades en el diseño orientado a objetos? Un
modelo de clase puede definir docenas y hasta cientos de clases de software,
y una aplicación tal vez requiera el cumplimiento de cientos o miles de
responsabilidades. Durante el diseño orientado a objetos, cuando se definen
las interacciones entre los objetos, se toman decisiones sobre la asignación
de responsabilidades a clases. Si se hace en forma adecuada, los sistemas tienden
a ser más fáciles de entender, mantener y ampliar, y se nos presenta la
oportunidad de reutilizar los componentes en futuras aplicaciones. |
|
|
Solución: |
Asignar
una responsabilidad al experto en información: la clase que cuenta con la
información necesaria para cumplir la responsabilidad. |
|
|
Ejemplo: |
En
la aplicación del punto de venta, alguna clase necesita conocer el gran total
de la venta. |
|
|
Beneficios: |
Se
conserva el encapsulamiento, ya que los objetos se
valen de su propia información para hacer lo que se les pide. Esto provee un
bajo nivel de acoplamiento, lo que favorece el hecho de tener sistemas más
robustos y de fácil mantenimiento. El
comportamiento se distribuye entre las clases que cuentan con la información
requerida, lo que ayuda a definir clases "sencillas" y más
cohesivas, que son más fáciles de comprender y mantener. |
|
A partir de esta recomendación, se puede plantear la
pregunta: ¿Quién es el responsable de conocer el gran total de la venta?
Desde el punto de vista del patrón Experto, deberíamos buscar la clase
de objetos que posee la información necesaria para calcular el total. Por
ejemplo:
¿Qué información hace falta para calcular el gran
total? Hay que conocer todas las instancias VentaLineadeProducto de una
venta, y la suma de sus subtotales, y esto lo conoce únicamente la instancia Venta. Por tanto, desde el punto de
vista del Experto, Venta es la
clase de objetos correcta para asumir esta responsabilidad. Venta es el experto en información. Entonces:
Todavía no terminamos. ¿Qué información hace falta
para determinar el subtotal de la línea de productos? Se necesitan VentasLineadeProducto.cantidad
y EspecificaciondeProducto.precio.
VentasLineadeProducto
conoce su cantidad y su correspondiente EspecificaciondeProducto. Por
tanto, desde la perspectiva del patrón Experto,
VentasLineadeProducto
debería calcular el subtotal.
VentasLineadeProducto no puede cumplir la responsabilidad de conocer y dar
el subtotal, si no conoce el precio del producto. EspecificaciondeProducto es un
Experto en información para contestar su precio. Por tanto, habrá que enviarle
un mensaje preguntándole el precio.
En conclusión, para cumplir con la responsabilidad de
conocer y dar el total de la venta, se asignaron tres responsabilidades a las
tres clases de objetos:
|
Clase |
Responsabilidad |
|
Venta |
Conoce
el total de la venta |
|
VentasLineadeProducto |
Conoce
el subtotal de la línea de producto |
|
EspecificaciondeProducto |
Conoce
el precio del producto |
Note
que el cumplimiento de una responsabilidad requiere a menudo información
distribuida en varias clases de objetos. Es decir, hay muchos "expertos
parciales" que colaboran en la tarea. Cuando la información se encuentre
esparcida entre varios objetos, éstos tendrán que interactuar a través de
mensajes para compartir el trabajo.
referencias
Infografía
http://exa.unne.edu.ar/depar/areas/informatica/anasistem2/public_html/apuntes/maf/cap2.htm
http://www.monografias.com/trabajos10/andi/andi.shtml#dete
http://www.dcc.uchile.cl/~luguerre/cc40b/clase2.html
http://www.ecomchaco.com.ar/utn/disenodesistemas/apuntes/
http://www.fi-b.unam.mx/pp/profesores/carlos/aydoo/toc.html
http://www.di.uniovi.es/~cernuda/pfc/aoo.pdf
http://www.elprisma.com/apuntes/apuntes.asp?page=15&categoria=602
Bibliografía
Pérez,
Yaros. “ANÁLISIS Y DISEÑO DE SISTEMAS”Publicación Digital. TRAIN4YOU.Caracas
1998-2004.