m2 metodologia de analisis as

5/25/2018 M2 Metodologia de Analisis As

1/83

CURSO DE PROGAMADOR DE

APLICACIONES INFORMTICAS

Metodologas de Anlisis

(Anlisis de Sistemas)

PABLO LUJN MARTNEZ


2/83

Curso FPO de Programador de Aplicaciones.Metodologas de Anlisis

Introduccin:

Podemos definirla como la documentacin de los requisitosesenciales (funciones, rendimiento, diseo, restricciones y atributos) delsoftware y de sus interfaces.

Para que la ERS sea eficaz debe tener las siguientes caractersticas:

Debe incluir informacin cierta; coherente con las necesidades

reales del usuario que se desean satisfacer.

Debe comunicar dicha informacin de forma eficaz.


3/83


Caractersticas de una buena ERSI. No Ambigua.

II. Completa.

III. Fcil de Verificar.

IV. Consistente.

V. Clasificada por importancia o estabilidad.

VI. Fcil de Modificar

VII. Fcil identificacin del origen y de las consecuencias de cada requisito.VIII. De fcil utilizacin durante la fase de explotacin.


4/83


Caractersticas de una buena ERSI. No Ambigua: Se intentara, en la medida de lo posible, que cada requisito

solo tenga una nica interpretacin.

II. Completa: Diremos que ERS esta completa si:

a. Incluye todos los requisitos significativos del software.

b. Define la respuesta del software a todas las posibles clases de datosde entrada y en todas las posibles situaciones.

c. Esta conforme con cualquier estndar de especificacin que se debacumplir.

d. Estn etiquetadas y referenciadas en el texto todas las figuras,tablas y diagramas.


5/83


Caractersticas de una buena ERS

III. Fcil de Verificar: Diremos que es fcil de verificar si y solo si existe algnprocedimiento finito y efectivo en coste para que una persona o maquinacompruebe el software satisface dicho requisito.

IV. Consistente: Es consistente si y solo si ningn conjunto de los requisitosdescritos en ella son contradictorios o entran en conflicto.

V. Clasificacin por orden de importancia: Se ordenaran los requisitos enbase a su prioridad (por importancia) o en funcin de se estabilidad.


6/83



VI. Fcil de modificar: Diremos que es fcilmente modificable si su estructuray estilo permiten cualquier cambio necesario en los requisitos (fcil,completa y consistentemente). Eso implica:

Tener una organizacin coherente y manejable, con una tablade contenidos, un ndice y referencias cruzadas.

No ser redundante.


7/83



VII. Facilidad para identificar el origen y las consecuencias de cada requisito:Cumpliremos este requisito si se establece un origen claro para cada unode los requisitos y si posibilita la referencia de estos requisitos endesarrollos futuros. Utilizaremos dos tipos de referencias:

Referencias hacia atrs: Depende de que los requisitos hagan

referencia a los documentacin realizada previamente.

Referencias hacia adelante: Depende de los documentos originadospreviamente el ERS.


8/83



VIII. Facilidad de utilizacin en la fase de explotacin y mantenimiento:Hay que tener en cuenta las necesidades de mantenimiento, incluyendola actualizacin/sustitucin del software. Esto se debe a:

El personal que realiza el mantenimiento, generalmente, no haestado involucrado en el desarrollo. Por lo que debemos tener unaERS fcilmente modificable y constar de un registro con las

caractersticas especiales de cada componente. Gran parte de los conocimientos y de la informacin necesaria para

el mantenimiento se dan por supuestos en la organizacin deldesarrollo. Pero suelen estar ausentes en la organizacin delmantenimiento.


9/83


ESTRUCTURA PARA LA ERS

1. Introduccin

1. Objetivo.2. mbito.3. Definiciones, siglas y abreviaturas.4. Referencias.5. Visin Global

2. Descripcin General1. Perspectiva del Producto.

2. Funciones del Producto.3. Caractersticas del Usuario.4. Limitaciones Generales.5. Supuestos y Dependencias.


10/83



3. Requisitos especficos

1. Requisitos Funcionales1. Requisitos Funcional 11. Introduccin2. Entradas3. Procesamiento4. Salidas

2. Requisito Funcional 2

1. Introduccin2. Entradas3. Procesamiento..


11/83



3. Requisitos especficos

2. Requisitos de interfaz externa1. Interfaces de usuario2. Interfaces de hardware3. Interfaces de software4. Interfaces de comunicaciones

3. Requisitos de ejecucin

4. Requisitos de diseo1. Acatamiento de Estndares2. Limitaciones Hardware


12/83



3. Requisitos especficos5. Atributos de Calidad

1. Seguridad2. Mantenimiento

6. Otros requisitos1. Base de datos2. Operaciones3. Adaptacin de situacin

Apndicesndices


13/83


Aparece como una tcnica para modelar las funciones que debe realizar elsistema y los datos que fluyen a travs de ella. A finales de los 70, DeMarco,

define esta tcnica que se apoya en la descripcin textual y lasespecificaciones del proceso.

Un diagrama de flujo de datos es un diagrama en forma de red querepresenta el flujo de datos y las transformaciones que se aplican sobre ellosal moverse desde la entrada hasta la salida del sistema.

Estos diagramas se utilizan para modelar las funciones del sistema y losdatos que fluyen entre ellas a distintos niveles de abstraccin.


14/83


Los componentes de un DFD son:

Procesos

Almacenes

Entidades Externas

Flujo de Datos


15/83



Procesos (funciones o transformaciones):

Representa una funcin que transforma los flujo de datos de entrada enuno o varios flujos de datos de salida.

Este debe ser capaz de generar los flujos de datos de salida a travs delos flujos de datos de entrada mas una informacin local (regla de

conservacin de datos).Cuando se realizan los DFD lgicos, los procesos no deben estar ligadosa cualquier connotacin fsica. Si se realizan DFD fsicos si se puedenincluir este tipo de connotaciones.


16/83



Almacn de Datos I:

Representa la informacin del sistema almacenada de forma temporal.

Es un depsito lgico de almacenamiento y puede representar cualquierdato temporalmente almacenado independientemente del dispositivoutilizado.


17/83



Almacn de Datos II:

Los almacenes de datos tienen las siguientes caractersticas:

Todos los almacenes de datos deben llevar un nombre lo masrepresentativo posible y no debe estar asociado a connotacionesfsicas.

Un almacn de datos se puede representar varias veces en un DFDsi con ello se mejora la interpretacin del diagrama.

Si en un DFD hay un almacn que solo tiene conexin con unproceso, se dice que el almacn es local al proceso.


18/83



Almacn de Datos III:

Los almacenes de datos tienen las siguientes caractersticas:

Un almacn se dice que tiene estructura simple cuando es de tiporegistro.

El contenido de un almacn con una estructura mas compleja sepuede representar mediante un diagrama de entidad/interrelacin.


19/83



Entidades Externas I:

Representa un generador o consumidor de informacin del sistema queno pertenece al mismo (subsistema, persona, departamento, otraaplicacin, otro sistema).


20/83



Entidades Externas II:

Aspectos que debemos tener en cuenta respecto a las entidadesexternas:

Son externas al sistema que se esta definiendo. Los flujos queentran o salen de ellas definen la interfaz entre el sistema y el

mundo exterior.

Las relaciones entre entidades externas no son objeto del estudiodel modelo.


21/83



Entidades Externas III:

El nombre para indicar la entidad externa debe ser representativo. Aligual que en los almacenes de datos podremos dibujarlas variasveces en nuestro esquema para facilitar la interpretacin de este.

Normalmente las entidades externas solo aparecern en el DFD demayor nivel (diagrama de contexto).


22/83


Yourdon ,DeMarco

Gane y Sarson SSADM Mtrica

Flujo de Datos

Procesos

Almacenes de

datos

Entidades externas


23/83



Flujos de Datos:Un flujo de datos es el camino por el que circulan los datos de un sistemaa otro.

Mediante estos flujos conectamos el resto de componentes que

introducimos en el DFD.

Estos flujos de datos los podemos clasificar en discretos o continuos.


24/83



Flujos de Datos II:Los flujos de datos discretos representan datos en movimiento enmomento determinado.

Los flujos de datos continuosson un caso especifico de los anteriores

que representa flujos de datos persistentes en el tiempo.

La conexin entre dos procesos mediante un flujo de datos ser posiblesiempre y cuando la informacin sea sncrona.


25/83



Flujos de Datos III:

ProcesoA

ProcesoB

Paso sncronode informacin entreprocesos.

ProcesoA

ProcesoBALMACEN TEMPORAL

Paso asncronode informacin entreprocesos.


26/83



Flujos de Datos IV:Conexiones entre proceso y almacenes:

Flujo de consulta: muestra la utilizacin de la informacin delalmacn para una de las siguientes:

Utiliza los valores de uno o mas atributos de una ocurrencia del

almacn. Comprobar si los valores de los atributos seleccionados

cumplen los criterios.


27/83



Flujos de Datos V:Conexiones entre proceso y almacenes:

Flujo de actualizacin: indica el proceso que va a modificar los datoscontenidos en el almacn para:

Crear una nueva entrada o establecer una relacin nueva.

Borrar una o mas entradas o relaciones. Modificar el valor de un atributo.


28/83



Flujos de Datos VI:

Conexiones entre proceso y almacenes:

Flujo de dialogo: Representa un flujo de consulta y un flujo deactualizacin que no tienen una relacin directa.


29/83



Flujos de Datos VII:

FLUJO DE ACTUALIZACIN FLUJO DE CONSULTA FLUJO DE DIALOGO


30/83



Flujos de Datos VII:

GESTIONARPETICIONES

DELCLIENTE

CLIENTES

INFORMES

CLIENTES

Informe aCliente

Peticin deInforme


31/83



Flujos de Datos VIII:Resumiendo los flujos de datos tienen las siguientes caractersticas:

Nombre Representativo.

Si los datos que viajen en el flujo tienen varias finalidades o no viajanjuntos, estos estarn representados por varios flujos.

El contenido de un flujo puede ser : Elemento (o atributo), Grupo (oconjunto de atributos), Par de Dialogo, Mltiple.


32/83



Flujos de Datos IX:Resumiendo los flujos de datos tienen las siguientes caractersticas(cont.):

Los flujos de datos se pueden desdoblar en varios flujos o aparecerrepetido.

Los flujos de datos no indican el control de ejecucin de un procesoni cuando se ejecutan estos.


33/83


Descomposicin en niveles de un DFD

La idea principal es representar el modelo por capas. Donde cada capa serepresentara mediante un diagrama de flujo de datos. Lo realizaremos siguiendoun diseo Top-Down, obteniendo por cada nivel un a visin mas detallada. Estaforma de trabajo nos proporciona las siguientes ventajas:

o Ayuda a construir la especificacin de arriba abajo.

o Los distintos niveles puede ir dirigidos a distintas personas.o Facilita el trabajo de los analistas que pueden trabajar paralelamente

modelando funciones diferentes del sistema.

o Facilita la documentacin del sistema.


34/83



Comenzaremos siempre por el nivel mas alto de la jerarqua mediante un DFD, aeste nivel lo llamaremos diagramade contexto o diagrama 0*. En este diagramasolo hay un proceso que representa el sistema completo.

Este proceso lo dividimos en otro DFD , llamado diagrama de sistema, en donde serepresenta las principales funciones o subsistemas.

Con los procesos definidos, los vamos descomponiendo cada vez en procesos massimples. As sucesivamente hasta que no sea necesario crear mas procesos.


35/83



Por lo tanto un conjunto de DFD esta formado por:oDiagrama de Contexto (nico).

oNiveles Medios, formado por el resto de diagramas.

oFunciones primitivas, presentes desde los niveles intermedios a los ltimosniveles de la jerarqua. Se corresponde con procesos que no se puedendescomponer en otros DFD.


36/83



Diagrama de Contexto: Es el primer diagrama de la jerarqua. El objetivo deeste diagrama es delimitar la frontera entre el sistema con el mundo exterior ydefinir sus interfaces (flujos de datos de entra y salida) entre el sistema y suentorno.

E1

E3

E20

GestinSistema

A B

C


37/83



Diagrama de 0 (diagrama del sistema):Diagrama sobre el que se descomponeel sistema. En este diagrama representamos las funciones principales que deberealizar as como las relaciones entre ellas.

1

A A1

B 2

C


38/83



Procesos Primitivos:Son aquellos procesos de un DFD que ya no se puedendescomponer en mas diagramas de nivel inferior. Esta funcin primitiva constara deuna especificacin que la describa.

La decisin de no descomponer mas es decisin del analista. Para ello vamosa definir una serie de reglas que nos ayuden a realizar esto:

oCuando un requisito funcional se puede especificar en menos de una pgina

mediante un lenguaje de especificacin o pseudocdigo.oCuando los procesos del diagrama tienen pocos flujos de datos de entrada ysalida.

oCuando al descomponer una funcin de un nivel determinado, se pierde elsignificado de lo que tiene que hacer esa funcin.


39/83



Consistencia entre Niveles: BALANCEODiremos que un nivel es consistente entre los distintos niveles de un DFD si la

informacin que entra y sale de un proceso N es consistente con la informacin queentra y sale del DFD que se descompone.

Para ello seguimos la regla del balanceo. Esta consiste en:

Todos los flujos de datos que entran en un diagrama hijo deben estar

representados en el padre por el mismo flujo de datos entrando al procesoasociado.

Las salidas del diagrama hijo deben ser las mismas salidas del proceso padreasociado.


40/83



Convenciones a la numeracin:Para numera los diagramas y procesos seguiremos las siguientes indicaciones:

1. Cada diagrama recibe el nmero y el nombre del proceso quedescompone.

2. El proceso de diagrama de contexto es siempre numerado con 0

3. Los procesos del diagrama de sistema se enumeran por un enterocomenzando por 1.

4. En los restantes niveles, los nmeros de procesos estar formado por laconcatenacin del nmero de diagrama en el que estn mas un punto y unnmero entero nico para identificarlo dentro del diagrama.


41/83



Recomendaciones en la creacin de un DFD:La creacin de un DFD no es una tarea fcil. Durante la construccin se

realizan cambios continuos debidos a:

o La construccin se realiza mediante un proceso de refinamiento iterativo delos mismo. Es casi imposible crea los DFD correctamente a la primera.

o Al comenzar el modelado no se conocen todas las caractersticas delsistema.


42/83



Recomendaciones en la creacin de un DFD II:Creacin de DFD

1. Se debe crear el diagrama de contexto, localizando todas las entidades externasque van a proporcionar y/o consumir informacin, as como su composicin.

2. Se debe crear el diagrama de sistema enfocndose en sus funcionesprincipales.

3. Nos centraremos en cada proceso sealando sus entradas y salidas, recogidasdel diagrama de contexto.

4. Luego observaremos los tipos de flujos (asncronas y sncronas). Observaremosque la comunicacin de un proceso con estos flujos se descompondr con lacomunicacin de dos procesos a un nivel inferior.


43/83



Recomendaciones en la creacin de un DFD II:Creacin de DFD

5. Para el resto de diagramas, lo principal es no descomponer al mximo.

6. Recogeremos todas las interfaces del proceso de nivel superior y lasasignaremos a cada subfuncin, pudiendo desglosar el contenido de flujosmltiples.

7. Evitaremos que un diagrama de nivel inferior conste de dos redesdesconectadas.

8. Evitaremos en la medida de lo posible el particionamiento desigual.


44/83



Recomendaciones en la creacin de un DFD II:Modificacin de DFD

Si la independencia funcional esta bien conseguida, la modificacin de los DFDresultara fcil.

Ante una nueva funcionalidad habr que estudiar en que nivel de abstraccin seencuentra para incluirla en el diagrama correspondiente, asi como establecersus relaciones.


45/83


Definiremos un diccionario de datos (DD) como una lista organizada de los

datos utilizados por el sistema que grficamente estn representados por los flujosde datos y almacenes presente en el DFD

El DD se crea a la vez que los DFD durante el anlisis del sistema. Lasentradas son realizadas cada vez que se identifica un elemento y pueden ser detres tipos: flujos de datos, almacenes y datos elementales.

Estas entradas so n nic as para cada componente del DFD.


46/83


La definicin de los flujos se realiza siguiendouna aproximacin top-down. Los componentes se irn definiendo mediantecomponentes mas detallados. Esto se descompondrn hasta obtener partes

indivisibles.

Un flujo de datos se puede definir tericamente mediante la inclusin (+),seleccin ([ ]) e iteracin ({ }) de sus componentes.


47/83


= Composicin: esta compuesto de, o es equivalente a

+ Inclusin: y[] Seleccin: seleccin de una de las opciones encerradas

entre corchetes

{} Iteracin: iteraciones del campo encerrado entre llaves

() Opcin: significa que el componente encerrado esopcional.

*texto* Comentario

@ Identificador: se utiliza para sealar un campo oconjunto de campos que identifican cada ocurrencia deun almacn


48/83


PETICION LIBROS = CARNET BIBLIOTECA + FICHA LIBROS

- Composicin (=): Si tenemos un flujo A que este compuesto de un flujo B y un

flujo C, lo representamos: A = B + C.

Si tenemos un cliente que realiza una peticin de prstamo a una biblioteca,debiendo entregar el carnet de la biblioteca y una ficha en donde se rellena lainformacin del libro a retirar.

Esto lo expresariamos:


49/83


CLIENTE = NOMBRE + DOMICILIO + [NIF|CIF]

- Seleccin ( [] ): Se representa por unos corchetes, separando cada opcin con |.

Tratamos de distinguir entre campos alternativos y no entre las diferentesopciones.

Para el cliente de una empresa, este puede ser una persona o una empresa.


50/83


- Iteracin ( {} ): Se representa por los smbolos indicados entre parntesis.

En el ejemplo de la biblioteca la ficha de libros puede contener varios libros(signatura, titulo, autor).

Esto se representara:

Si queremos representar los limites inferior y superior los indicaremos al principio yfinal de los caracteres de delimitaciones.

FICHA LIBROS = {LIBROS}

LIBROS = SIGNATURA + TITULO + AUTOR


51/83


DATOS_CLIENTE = DNI + NOMBRE + APELLIDOS +

(NMERO DE TELEFONO)

- Opcin ( () ): Se representa con los parntesis e indica si el campo puede o noestar presente. Para almacenar los datos de un cliente habr campos como elnmero de telfono que son opcionales.

As definiremos los datos del cliente como:


52/83


LIBROS DISPONIBLES = @SIGNATURA + TITULO + AUTOR +NMERO DE UNIDADES

Los almacenes se definen como entidades repetitivas de datos y/o grupo de

datos. El analista escoger uno o mas datos para organizar la coleccin deentradas del almacn, es lo que llamamos identificador

En un almacn que incluya los libros que tenemos disponibles losrepresentaremos de la siguiente manera:


53/83


La especificacin de procesos (o miniespecificacin) es una tcnica que define elprocedimiento que realiza un proceso primitivo.

Describir de una manera formal como se obtienen los flujos de salida a travs delos flujos de entrada. Las alternativas para realizar esto son:

Lenguaje estructurado (pseudocdigo)

Arboles de decisin.

Tablas de decisin.

Diagramas de flujo.


54/83


El modelo entidad-relacin lo defini Peter P. Chen en 1976. Segn este Elmodelo E/R puede ser usado como una base para una vista unifica de datos,adoptando elenfoque mas natural del mundo real que consiste en ENTIDADES e

INTERRELACIONES.

Entidad: Es aquel objeto mediante el cual queremos almacenar unainformacin en la base de datos. Segn ANSI, lo define como unapersona,lugar, cosa, concepto o suceso, real o abstracto, de inters para la empresa.


55/83


Entidad II: Diferenciaremos entre dos tipos de identidades:

o Regulares: Son aquellas que tienen que existir por necesidades obviasde nuestro proyecto.

o Dbiles: Son aquellas entidades que dependen de otras entidades.

EMPLEADO

FAMILIARES


56/83


Interrelacin: Llamaremos interrelacin a la correspondencia existente entreentidades, representada mediante un rombo.

Departamento Empleadopertenece

1:N


57/83


Interrelacin II: En una interrelacin tenemos los siguiente elementos.

o Nombre: Mediante el cual se hacer referencia a la relacin entre lasentidades.

o Grado: Nmero de entidades que participan en una interrelacin.

o Cardinalidades de las entidades: Corresponde al nmero mximo ymnimo de ocurrencias de un tipo de entidad que puedan estarinterrelacionadas con una ocurrencia de la otra entidad.

o Tipo de Correspondencia: Es el nmero mximo de ocurrencias de cadatipo de entidad que pueden intervenir en la interrelacin que se estatratando.


58/83


Atributo: Cada una de las propiedades o caractersticas que tiene un tipo deentidad o un tipo de interrelacin. Los atributos los representaremos con uncirculo y en su interior indicaremos el nombre del atributo.

De todos los atributos de una entidad elegiremos un conjunto de ellos (uno ovarios) que identifiquen unvocamente cada una de las ocurrencias. A estaagrupacin la llamares la clave de la entidad.


59/83


Una vez obtenido los requisitos del sistema. Definiremos como va a ser nuestromodelo E/R. Para ello tendremos en cuenta los siguientes pasos:

I. Un nombre comn que identifica el conjunto de nuestra entidad.

II. Los nombre propios indican ocurrencias de un tipo de entidad.

III. Un verbo indicar una interrelacin.

IV. Una preposicin o frase preposicional entre dos nombres suele ser un tipo deinterrelacin o establecer la asociacin entre una entidad y sus atributos.


60/83



61/83


TEORA DE LA NORMALIZACIN DE TABLAS

La teora de la normalizacin nos ayuda a prevenir los problemas de redundancia yanomalas de modificacin, insercin o borrado en los esquemas de base de datos.

La normalizacin consiste en realizar descomposiciones de los registros en otrosregistros de menor tamao de forma que satisfagan una serie de restricciones. Aesto se le llama forma normal.


62/83


TEORA DE LA NORMALIZACIN DE TABLAS (FORMAS NORMALES)

Primera forma norm al (1FN) I

Una relacin est en primera forma normal si, y slo si, todos los dominios de la mismacontienen valores atmicos, es decir, no hay grupos repetitivos. Si se ve la relacingrficamente como una tabla, estar en 1FN si tiene un solo valor en la interseccin decada fila con cada columna.

Si una relacin no est en 1FN, hay que eliminar de ella los grupos repetitivos. Ungrupo repetitivo ser el atributo o grupo de atributos que tiene mltiples valores paracada tupla de la relacin.


63/83



Primera form a no rmal (1FN) II

Hay dos formas de eliminar los grupos repetitivos. En la primera, se repiten losatributos con un solo valor para cada valor del grupo repetitivo. De este modo, seintroducen redundancias ya que se duplican valores, pero estas redundancias seeliminarn despus mediante las restantes formas normales. La segunda forma deeliminar los grupos repetitivos consiste en poner cada uno de ellos en una relacinaparte, heredando la clave primaria de la relacin en la que se encontraban.

Un conjunto de relaciones se encuentra en 1FN si ninguna de ellas tiene gruposrepetitivos.


64/83



Primera form a no rmal (1FN) III

Ejemplo:Tenemos una empresa pblica donde los puestos de trabajo estn regulados por elEstado, de modo que las condiciones salariales estn determinadas por el puesto. Seha creado el siguiente esquema relacional

EMPLEADOS(nss, nombre, puesto, salario, emails) con nsscomo clave primaria.


65/83



Primera forma norm al (1FN) IV

Ejemplo (cont.):Tenemos dos soluciones: En la primera cambiaremos la clave al conjunto formado pornss y el email. Duplicando la informacin nombre, puesto y salario.


66/83



Primera forma no rmal (1FN) V

Ejemplo (cont.):Tenemos dos soluciones: En la segunda solucin podemos separa la informacin delmail en otra tabla. Obteniendo el siguiente resultado.

Empleados Emails


67/83



Segunda form a norm al (2FN) I

Una relacin est en segunda forma normal si, y slo si, est en 1FN y, adems, cadaatributo que no est en la clave primaria es completamente dependiente de la claveprimaria.

La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o

ms atributos. Si una relacin est en 1FN y su clave primaria es simple (tiene un soloatributo), entonces tambin est en 2FN. Las relaciones que no estn en 2FN puedensufrir anomalas cuando se realizan actualizaciones.


68/83



Segunda form a normal (2FN) II

Para pasar una relacin en 1FN a 2FN hay que eliminar las dependencias parciales dela clave primaria. Para ello, se eliminan los atributos que son funcionalmentedependientes y se ponen en una nueva relacin con una copia de su determinante (losatributos de la clave primaria de los que dependen).


69/83



Segunda forma n orm al (2FN) III

Ejemplo: Retomemos la primera solucin del ejemplo de la primera forma normal.Definimos las dependencias funcionales siguientes:

nss nombre, salario, email.

puestosalario.

Como la clave que tenamos , (nss, email), las dependencias de nombre, salario y

email son incompletas. Para ello si separamos el email de la tabla original y creamosotra tabla. Llegamos a la solucin segunda propuesta en el ejemplo de la primeraforma normal.


70/83



Tercera fo rma no rmal (3FN) I

Una relacin est en tercera forma normal si, y slo si, est en 2FN y, adems, cadaatributo que no est en la clave primaria no depende transitivamente de la claveprimaria. La dependencia x Z es transitiva si existen las dependencias x y, y z,siendo x e y atributos o conjuntos de atributos de una misma relacin.

Aunque las relaciones en 2FN tienen menos redundancias que las relaciones en 1FN,todava pueden sufrir anomalas frente a las actualizaciones. Para pasar una relacinde 2FN a 3FN hay que eliminar las dependencias transitivas. Para ello, se eliminan losatributos que dependen transitivamente y se ponen en una nueva relacin con unacopia de su determinante (el atributo o atributos no clave de los que dependen).


71/83



Tercera form a normal (3FN) II

Ejemplo: Siguiendo el ejemplo anterior, podemos detectar la siguiente transitividad:

nss->puesto

puesto->salario

Tendremos la siguiente divisin de la tabla de empleado:Empleado Puesto

C O


72/83


En la mayora de las metodologas de desarrollo orientado a objetos se utiliza, entreotras, la tcnica del modelo de casosde uso. Los casos de uso tienen dos funcionesprincipales:

1. Capturar los requisitos funcionales del sistema

2. Simplificar la construccin de los modelos de objetos, que est dirigida a loscaso de uso. Esto se emplean durante toda las fases del desarrollo ydeterminan el resto de los modelos de la metodologa.

C FPO d P d d A li i


73/83


Un modelo de casos de uso es un grado con dos tipos de nodos:

Actores: Representa cualquier cosa que intercambia informacin con el sistema.

Caso de uso: Lo definimos como la secuencia de transacciones en un dialogocon el sistema que se encuentra relacionadas por su comportamiento.



74/83


Los arcos entre los actores y los casos de uso los llamaremos asociaciones. Los casosde uso se pueden relacionar entre ellos de las siguientes formas:

Extiende(): Permite que un caso de uso se inserte en otro. Dichode otra forma, es la especificacin de lo que realizamos en un paso con respectoal caso de uso que se relaciona.



75/83


Incluye(): Indica la inclusin del comportamiento de otro caso deuso.



76/83


Generalizacin : Permite representar la especializacin de un caso de uso.Esta asociacin tambin se puede aplicar a los actores.



77/83


La construccin del modelo de casos de uso es un proceso iterativo en el que puedenutilizarse distintas tcnicas de observacin o de entrevistas, mediante las cuales sevan describiendo los recursos potenciales desde el punto de vista del usuario.

Es importante destacar que el diagrama de casos de uso nos sirve nicamente para elpaso final del proceso de construccin.

Curso FPO de Programador de Aplicaciones


78/83


El proceso para identificar a seguir ser el siguiente:

1. Identificar casos:

1. Identificar limites del sistema y actores2. Identificar los casos de uso analizando el comportamiento de cada actor.

2. Descripcin y estructuracin de casos:

1. Descripcin completa de cada caso de uso

2. Estructurar casos detectando sus relaciones.

3. Documentar el diagrama de casos.

Los casos de uso se describen utilizando el lenguaje natural.



79/83


El modelo de clases lo podemos ver como una extensin del modeloentidad/relacin. El elemento principal es la clase.

La clase es la descripcin de los objetos del sistema que se quiere disear;objetos que comparten la estructura, el comportamiento y las relaciones.

En la fase de anlisis se construir el modelo conceptual de clases querepresenta los conceptos de informacin del sistema.

Esto lo visualizaremos mediante un modelo de clases que solo tiene losatributos y las relaciones entre las clases. Su estructura viene determinado por losatributos y su comportamiento lo determina el conjunto de operaciones de los objetosde la clase.



80/83


En la notacin UML las clases se representa por rectngulos, en los queindicamos el nombre, los atributos y las operaciones. Tanto para los atributos comopara las operaciones podemos indicar la visibilidad con los siguientes smbolos:

- (+) : Pblica.

- (#) : Protegida.

- (-) : Privada.



81/83


Tambin podemos indicar en los atributos su multiplicidad, si los valorespresentan un orden, el tipo del atributo y su valor inicial.

Para los operaciones podemos definir la lista de parmetros, el tipo devuelto yalguna propiedad de la operacin.

UML permite estereotipar las clases para indicar cuando actan como un tipo

de objetos pero sin definir su implementacin fsica, se denota como . Ocomo una clase de implementacin que define una estructura de datos y sus mtodospara lenguajes como C++, Smalltalk, etc...; se conoce como



82/83


En los diagramas de clases se suelen representar cuatro tipos de relaciones:

I. Asociacin: Puede ser binara (una lnea) o de grado superior (rombo que conectalas clases). Al lado indicaremos el nombre de la asociacin indicando la

direccionalidad con una flecha o triangulo. Le podemos aadir a esta relacinatributos, operaciones e indicar la cardinalidad.

II. Generalizacin: Se representa con una flecha con punta blanca hacia lasuperclase.

III. Agregacin/Composicin: Representa el concepto de que un objeto de una claseforma parte de otro objeto. Se representa con un rombo blanco. Solo se pude

incluir en un compuesto a la vez.IV.Dependencia: Indica la relacin entro dos elementos del modelo y se representa

mediante una flecha discontinua entre el elemento clientey el elemento servidor



83/83


m2 metodologia de analisis as

Documents

metodologia de analisis

requisitos fcil

curso fpo de programador

fcil utilizacin

fcil identificacin

fcil de modificarvii

requisitos enbase

requisitos significativos