TRABAJO
1
Investigar la diferencia entre Análisis y
Diseño Estructurado y Orientado a Objetos.
1.- DEFINICION:
1.1 Análisis y Diseño de Sistemas
Una definición básica de sistema es la
siguiente: Grupo de elementos interdependientes o que interactúan regularmente
formando un todo, a continuación se enumeran diversos ejemplos. Un sistema
gravitacional, un sistema termodinámico, un sistema de ríos, un sistema
telefónico, un sistema de autopistas, el sistema newtoniano de la mecánica, el
sistema de mecanografía al tacto, un sistema taxonómico, el sistema decimal,
etcétera.
Dependiendo de los objetivos del análisis
podemos encontrarnos ante dos problemáticas distintas:
- Análisis de un sistema ya existente para comprender, mejorar,
ajustar y/o predecir su comportamiento.
- Análisis como paso previo al diseño de un nuevo sistema-producto.
En cualquier caso, podemos agrupar más
formalmente las tareas que constituyen el análisis en una serie de etapas que se
suceden de forma iterativa hasta validar el proceso completo:
- Conceptualización
Consiste en obtener una visión de muy alto nivel del sistema, identificando sus elementos básicos y las relaciones de éstos entre sí y con el entorno. - Análisis funcional
Describe las acciones o transformaciones que tienen lugar en el sistema. Dichas acciones o transformaciones se especifican en forma de procesos que reciben una entradas y producen unas salidas. - Análisis de condiciones
(o constricciones) Debe reflejar todas aquellas limitaciones impuestas al
sistema que restringen el margen de las soluciones posibles. Estas se
derivan a veces de los propios objetivos del sistema:
- Operativas, como son las restricciones físicas,
ambientales, de mantenimiento, de personal, de seguridad, etc.
- De calidad, como fiabilidad, mantenibilidad,
seguridad, convivencialidad, generalidad, etc.
- Construcción de modelos
Una de las formas más habituales y convenientes de analizar un sistema consiste en construir un prototipo (un modelo en definitiva) del mismo. - Validación del análisis
A fin de comprobar que el análisis efectuado es correcto y evitar en su caso la posible propagación de errores a la fase de diseño, es imprescindible proceder a la validación del mismo. Para ello hay que comprobar los extremos siguientes: - El análisis debe ser consistente y completo.
- Si el análisis se plantea como un paso previo
para realizar un diseño, habrá que comprobar además que los objetivos
propuestos son correctos y realizables.
1.3 Análisis Estructurado
1. Dirigido a
la primer etapa del proceso de desarrollo.
2. Se basa en
construir un modelo de las prácticas administrativas que deben ser realizadas
por el nuevo sistema (desde el punto de vista lógico).
3. Es crítica en
esta fase la determinación y la definición de requerimientos ya que el fracaso
de las especificaciones rompen todo el esfuerzo de desarrollo.
4. Se busca
conocer y especificar lo que se quiere.
5. Si no se
sabe lo que se desea no se puede esperar éxito.
6. Las salidas (output) del análisis
estructurado son (especificaciones estructuradas):
Diagrama de
Flujo de Datos Nivelado (DFD) o Modelo Lógico del Sistema. Permite identificar los mini sistemas y las
interfaces entre ellos.
Diccionario de
Datos correspondiente al DFD. Define la
composición y organización de las interfaces.
Mini
Especificaciones de los Procesos (Primitivas
Funcionales) que aparecen en el DFD. Se realizan a través de ingles, castellano
estructurado, árboles de decisión o tablas de decisión.
1.4
El Diseño Estructurado
1. Una vez
conocido ¿Que? (Análisis Estructurado), el Diseño Estructurado se
encarga del ¿Cómo?.
Vale decir, como implementar mejor el modelo en términos del costo total de por
vida del sistema (Desarrollo y Mantención).
2. El diseño
estructurado busca establecer la organización interna del software, produciendo
sistemas que sean fáciles de entender (y por ende de construir y mantener).
3. Las
salidas del análisis estructurado son entradas (input)
para el diseño estructurado.
4. Las
salidas (output) del diseño estructurado son:
Diagrama
Estructurado (estructura de
software).
Especificación
de Módulos.
Diccionario de
Datos del Sistema.
1.5 Análisis y Diseño Orientado al Objeto
Conceptos y Diagramas
La metodología de Grady
Booch usa los siguientes tipos de diagramas para
describir las decisiones de análisis y diseño, tácticas y estratégicas, que
deben ser hechas en la creación de un sistema orientado por objetos.
1. Diagrama de Clases. Consisten en un conjunto de clases y relaciones entre ellas. Puede
contener clases, clases paramétricas, utilidades y metaclases. Los tipos de relaciones son asociaciones,
contenencia, herencia, uso, instanciación y metaclase.
2. Especificación de Clases. Es usado para capturar toda la información
importante acerca de una clase en formato texto.
3. Diagrama de Categorias. Muestra clases agrupadas lógicamente bajo varias
categorías
4. Diagramas de transición de estados.
5. Diagramas de Objetos. Muestra objetos en el sistema y su relación lógica. Pueden ser
diagramas de escenario, donde se muestra cómo colaboran los objetos en cierta
operación; o diagramas de instancia, que muestra la existencia de los objetos y
las relaciones estructurales entre ellos.
6. Diagramas de Tiempo. Aumenta un diagrama de objetos con información acerca de eventos
externos y tiempo de llegada de los mensajes.
7. Diagramas de módulos. Muestra la localización de objetos y clases en módulos del diseño
físico de un sistema.Un diagrama de módulos
representa parte o la totalidad de la arquitectura de módulos del sistema.
8. Subsistemas.
Un subsistema es una agrupación de módulos, útil en modelos de gran escala.
9. Diagramas de procesos. Muestra la localización de los procesos en los
distintos procesadores de un ambiente distribuido.
Etapas y definición de entregas
a.- Análisis de requerimientos
- Funciones primarias del sistema: Principales entradas y salidas del sistema, referencias a
políticas, sistemas existentes o procedimientos, etc.
- Conjunto de mecanismos claves que el sistema debe proveer: estado de entrada, estado de salida y estados
esperados.
b.- Análisis de Dominio
- Diagrama de clases con
las abstracciones clave, identificando las clases del dominio claves y sus
relaciones
- Especificación de las clases
- Vistas de herencia. Diagramas
de clases con este tipo de relaciones
- Diagramas de escenarios de objetos
- Especificación de objetos,
que relacionan objetos y sus clases.
c.-Diseño
- Descripción de arquitectura,
que describe las decisiones más importantes de diseño como son el conjunto
de procesos, manejadores de bases de datos, sistemas operativos,
lenguajes, etc.
- Descripciones de prototipo,
que describen las metas y contenido de las implementaciones sucesivas de
prototipos, su proceso de desarrollo y la forma de probar requerimientos.
- Diagramas de Categorías
- Diagramas de clases en diseño, detallan las abstracciones de análisis con características de
implementación.
- Diagramas de objetos en diseño, muestran las operaciones necesarias para desarrollar una
operación
- Nuevas especificaciones
- Especificaciones de clases corregidas, muestra la especificación completa de los
métodos con algoritmos complicados, la implementación de relaciones y el
tipo de atributos.
2.- DIFERENCIA
|
Programación tradicional |
Programación actual |
|
Representación en modo texto |
Representación en modo gráfico |
|
Trabajo en mono-programa |
Trabajo en multi programación |
|
Trabajo en mono-tarea |
Trabajo en multi-tarea |
|
Ejecución controlada por el programa |
Ejecución controlada por el Sistema |
|
Programación de tipos fijos |
Programación orientada a objetos |
3.- CASO PRACTICO
SISTEMA DE GESTIÓN DE PERSONAL
Caso Práctico
utilizando UML: El Sistema
permite registrar la ficha básica del personal, el cual lo identifica en toda
la organización, se pueden consultar en cualquier momento los datos de un
usuario en particular, se registra información de la experiencia laboral,
formación académica, información sobre la organización a la cual trabaja
actualmente, otros aspectos.
Requerimientos
|
No |
Descripción |
|
Consultas / Informes |
|
|
R01 |
Reporte Indicadores de Personal |
|
R02 |
Reporte Experiencia Laboral |
|
R03 |
Adiestramientos recibidos a la fecha |
|
R04 |
Reporte de personal por gerencia |
|
R05 |
Reporte próximos a jubilar |
|
R06 |
Reporte personal con limitaciones |
|
No |
Descripción |
|
Almacenamiento |
|
|
R07 |
Ficha del Personal: C_PNOMBRE, C_SNOMBRE, C_PAPELIDO, C_SAPELLIDO, C_SEXO, D_FNAC, C_CEDULA, C_TELEFONO, C_COMPANIA, D_TELCOMPANIA, C. ESTADOCIVIL, C.DIRECCIÓNHABITACION,C.MAILPERSONAL D_FINGRESO |
|
R08 |
Experiencia Laboral: C_NOMBREEMPRESA, C.CARGO, D.DURACION, C.ACTIVIDADPRINCIPAL, C.MOTIVODECULMINACION LABORAL, D.AÑOEXPERIENCIA, D. AÑOEXPERIENCIAPDVSA. |
|
R09 |
Formación Académico: C.NIVELEDUCATIVO, C.PROFESIÓN, C.INSTITUTI_UNIVERSIDAD, D.AÑOGRADUACIÓN, D.AÑOSGRADUADO, C.MERITOSOBTENIDOS. C.OTROSESTUDIOS. |
|
R10 |
Formación
Complementaria (Historial de Adiestramientos): C.NOMBREDE
|
|
R11 |
Otros Conocimientos: C.IDIOMAS, C.NIVELDOMINIO, C.APTITUDES |
|
R12 |
Información sobre organización: C.DIVISION/UNIDADNEGOCIO, C.GERENCIA, C.SUPERINTENDENCIA, C.DICIPLINA, C.SECCION, C.UNIDAD, C.CARGO, C.POSICIÓNSAP, D.CENTRODECOSTO, D.FECHAASIGNACIONCARGO, D.TIEMPOEXPERIENCIACARGO, D.NIVELCARGO, |
|
R13 |
Otros Aspectos: C.TALLABRAGA, C.TALLACHEMISE,
D.TALLABOTAS, D.PANTALON,
D.FECHAVENCICARNET, D.FECHAVENCCERTIFICADOMEDICO,
D. FECHAVENCIMIENTOPERMISOMANEJO, C.CODIGOPERMISOMANEJO,
D.FECHAJUBILACION, C.LIMITACIONESMEDICAS,
C.DENOMINACIONCARGO, C.UBICACIONFISICATRABAJO,
C.MODALIDADCONTRATACION, C.TIPONOMINA,
D.FECHAINGRESOEMPLEADO, D.FECHAINICIOCONTRATOACTUAL,
D.FECHACULMINACIONCONTRATOACTUAL, D.FECHAPRIMERCONTRATOEMPRESA, C.EMAIL,
D.EXTEMPLEADO, C.SUPERVISOR,
D.EXTSUPERVISOR, D.CELULARSUPERVISOR
C.EMAILSUPERVISOR, C.NOMBRECONSULTORA,
C.GRUPOCLASIFICACION, D.SUELDOMENSUAL,
D.SUELDOANUAL |
|
No |
Descripción |
|
No |
Descripción |
|
Procesamiento |
|
|
R14 |
Calculo de Edad Personal: |
|
R15 |
Mostrar alerta un mes
antes, del vencimiento Fecha de vencimiento del carnet (fecha del sistema- D.FECHAVENCICARNET)=30 |
|
R16 |
Mostrar alerta cinco días
antes, del vencimiento Fecha de vencimiento del certificado medico (fecha del sistema- D.FECHAVENCCERTIFICADOMEDICO)=5 |
|
R17 |
Fecha de vencimiento del permiso de manejo (fecha del sistema- D. FECHAVENCIMIENTOPERMISOMANEJO) |
4.- INFOGRAFIA
1.- Análisis y Diseño de Sistemas: Grupo de elementos interdependientes
o que interactúan regularmente formando un todo.
www.emagister.com/ analisis-diseno-sistemas-cursos-1054306.htm
2.- Análisis y Diseño de Sistemas: Cada
sistema a desarrollar debe ser tratado con la metodología que mejor se adapte a
los objetivos del análisis un producto final de calidad.
http://www.monografias.com/trabajos15/analista-sistem/analista-sistem.shtml#ANALISIS
3.- Análisis y Diseño Estructurado: El análisis estructurado, es la primera etapa del proceso de
desarrollo, se basa en construir un modelo administrativo que se aplicará en el
nuevo sistema. En esta etapa Es crítica en esta fase la determinación y la
definición de requerimientos ya que el fracaso de las especificaciones rompen
todo el esfuerzo de desarrollo.
4.- Análisis y Diseño de Sistema: Este artículo refleja tareas que constituyen el
análisis en una serie de etapas que se suceden de forma iterativa hasta validar
el proceso completo del análisis y diseño de un sistema.
http://www.daedalus.es/AreasISAnalisis-E.php
5.- Análisis y Diseño Orientado
a Objeto: Muestra paso a paso la metodología de Grady Booch, para el análisis y
diseño de sistema.
http://www.cs.ualberta.ca/~pfiguero/soo/metod/ood.html
6.- Programación Orientada a
Objetos:
Este articulo refleja las diferencias de la programación tradicional y la
programación Orientada a Objeto, haciendo acotaciones que la programación
tradicional mezcla conceptos distintos e independientes, que se deben tener
claro para entrar en ala programación POO.