Qué es Análisis y Diseño Orientado a Objetos.docx

8/13/2019 Qu es Anlisis y Diseo Orientado a Objetos.docx

1/22

Pgina 1

NOMBRE DEL TRABAJO

TEMA UNIDAD 1

ARQUITECTURA Y DISEO DE SOFTWARE

MATERIA

ARQUITECTURA Y DISEO DE SOFTWARE

Catedrtico

M.I. JOSE JAHVEH CONTRERAS DE LOS REYESAlumnos

ANGEL GARCIA LOMAS

ALEJANDRA DEL C. NARANJOS ROMAN

ITZEL SALINAS RODRIGUEZ

Carrera

INGENIERIA EN SISTEMAS COMPUTACIONALES

SEMESTRE

OCTAVO

CD. ACUA, COAHUILA, MXICO 05/02/2013


2/22

Pgina 2

1.1Qu es Anlisis y Diseo Orientado a Objetos

Es un enfoque de la ingeniera de software que modela un sistema como un grupo de objetos que

interactan entre s.En este mtodo de anlisis y diseo se crea un conjunto de modelos utilizando

una notacin es decir un lenguaje unificado de modelado (UML)

ADOO aplica tcnicas de modelado de objetos para analizar los requerimientos y para disear una

solucin para mejorar los procesos involucrados

1.2 Referencias histricas.

Cada vez que se narra la historia de la arquitectura de software (o de la ingeniera de software,

segn el caso), se reconoce que en un principio, hacia 1968, Edsger Dijkstra, de la Universidad

Tecnolgica de Eindhoven en Holanda y Premio Turing 1972, propuso que se establezca una

estructuracin correcta de los sistemas de software antes de lanzarse a programar, escribiendo

cdigo de cualquier manera.

En 1969 Fred Brooks Jr y Ken Iverson llamaban arquitectura a la estructura conceptual de un

sistema en la perspectiva del programador.

En 1971, C. R. Spooner titul uno de sus ensayos Una arquitectura de software para los 70s,

En 1972, Parnas public un ensayo en el que discuta la forma en que la modularidad en el diseo

de sistemas poda mejorar la flexibilidad y el control conceptual del sistema, acortando los

tiempos de desarrollo.

En 1975, Brooks, diseador del sistema operativo OS/360 y Premio Turing 2000, utilizaba el

concepto de arquitectura del sistema para designar la especificacin completa y detallada de la

interfaz de usuario

la dcada de 1980, los mtodos de desarrollo estructurado demostraron no escalar

suficientemente y fueron dejando el lugar a un nuevo paradigma, el de la programacin orientada

a objetos.


3/22

Pgina 3

la dcada de 1990 fue sin duda la de la consolidacin y diseminacin de la AS en una escala sin

precedentes.

Uno de los acontecimientos arquitectnicos ms importantes del ao 2000 fue la hoy clebre tesis

de Roy Fielding que present el modelo REST, el cual establece definitivamente el tema de las

tecnologas de Internet y los modelos orientados a servicios.

1.2.1 OMT (Tcnica de Modelado de Objetos).

es una metodologa muy precisa y completa creada 1991 las faces que la conforman son

anlisis: es una abstraccion resumida y precisa de lo que debe hacer el sistema deseado.

diseo del sistema: el sistema se organisa en subsistemas basandose en el analisis como de suarquitectura.

diseo de objetos: se centra en la estructura de datos y algoritmos que son necesarios para

implementar en cada clase .

implementacin: las clases y objetos desarrolladas en la etapa de anlisis para ser im plementadas

y el sistemas sea flexible y extensible con el diseo de este.

este emplea tres clases de modelo:

modelo de objetos

modelo dinamico

modelo funcional

se acopla a las necesidades de ingenieria actuales y maneja varios modelos lo que hace que esta

metodologia se ha de las mas efiecientes.


4/22

Pgina 4

1.2.2 Metodologa Booch.

Booch en esencia plantea que para trabajar con su mtodo es conveniente trabajar en dos partes

fundamentales: un microproceso y un macroproceso. Ambas partes incluyen varios pasos como

son la identificacin de clases y objetos a un nivel de abstraccin,

la identificacin de la semntica de esas clases y objetos, la identificacin de las relaciones entre

esas clases y objetos, la seleccin de la estructura de datos y algoritmos para la implantacin de

estas clases y objetos, la conceptualizacin del sistema, etc.

El microproceso de desarrollo del AOO de Booch incluye:

Identificacin de clases y objetos. Proposicin de objetos candidatos.

Conduccin del anlisis de comportamiento. Identificacin de escenarios relevantes. Definicin de atributos y operaciones para cada clase. Identificacin de la semntica de clases y objetos. Seleccin y anlisis de escenarios. Asignacin de responsabilidades para alcanzar el comportamiento deseado. Divisin de las responsabilidades para equilibrar el comportamiento. Seleccin de un objeto y enumerar sus papeles y responsabilidades. Definicin de operaciones para satisfacer las responsabilidades. Bsqueda de colaboraciones entre objetos. Identificacin de interrelaciones entre clases y objetos. Definicin de las dependencias que existen entre objetos. Descripcin del papel de cada objeto participante. Validacin de escenarios por revisin completa. Realizacin de una serie de refinamientos. Produccin de los diagramas apropiados para el trabajo realizado en las partes anteriores. Definicin de jerarquas de clases apropiadas. Creacin de agrupamientos basados en clases comunes. Implementacin de clases y objetos.


5/22

Pgina 5

1.3 METODO RUP (RATIONAL UNIFIED PROCESS)

Las siglas RUP en ingles significa Rational Unified Process (Proceso Unificado de Rational) es un

producto del proceso de ingeniera de software que proporciona un enfoque disciplinado para

asignar tareas y responsabilidades dentro de una organizacin del desarrollo. Su meta es asegurar

la produccin del software de alta calidad que resuelve las necesidades de los usuarios dentro deun presupuesto y tiempo establecidos.

Dimensiones del RUP

El RUP tiene dos dimensiones:

El eje horizontal representa tiempo y demuestra los aspectos del ciclo de

vida del proceso.

El eje vertical representa las disciplinas, que agrupan actividades

definidas lgicamente por la naturaleza.

La primera dimensin representa el aspecto dinmico del proceso y se expresa en trminos de

fases, de iteraciones, y la finalizacin de las fases. La segunda dimensin representa el aspecto

esttico del proceso: cmo se describe en trminos de componentes de proceso, las disciplinas, las

actividades, los flujos de trabajo, los artefactos, y los roles.


6/22

Pgina 6

Se puede hacer mencin de las tres caractersticas esenciales que definen al RUP:

Proceso Dirigido por los Casos de Uso:Con esto se refiere a la utilizacin de los Casos de Uso

para el desenvolvimiento y desarrollo de las disciplinas con los artefactos, roles y actividades

necesarias. Los Casos de Uso son la base para la implementacin de las fases y disciplinas del RUP.

Un Caso de Uso es una secuencia de pasos a seguir para la realizacin de un fin o propsito, y se

relaciona directamente con los requerimientos, ya que un Caso de Uso es la secuencia de pasos

que conlleva la realizacin e implementacin de un Requerimiento planteado por el Cliente.

Proceso Iterativo e Incremental:Es el modelo utilizado por RUP para el desarrollo de un

proyecto de software. Este modelo plantea la implementacin del proyecto a realizar en

Iteraciones, con lo cual se pueden definir objetivos por cumplir en cada iteracin y as poder ir

completando todo el proyecto iteracin por iteracin, con lo cual se tienen varias ventajas, entre

ellas se puede mencionar la de tener pequeos avances del proyectos que son entregables alcliente el cual puede probar mientras se esta desarrollando otra iteracin del proyecto, con lo cual

el proyecto va creciendo hasta completarlo en su totalidad. Este proceso se explica mas adelante a

detalle.

Proceso Centrado en la Arquitectura:Define la Arquitectura de un sistema, y una arquitectura

ejecutable construida como un prototipo evolutivo. Arquitectura de un sistema es la organizacin

o estructura de sus partes ms relevantes.

Una arquitectura ejecutable es una implementacin parcial del sistema, construida para

demostrar algunas funciones y propiedades.

RUP establece refinamientos sucesivos de una arquitectura ejecutable, construida como un

prototipo evolutivo.

Fases del mtodo RUP


7/22

Pgina 7

Planeando las fases

El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce una nueva versin

del producto, cada ciclo est compuesto por fases y cada una de estas fases est compuesta por

un nmero de iteraciones, estas fases son:

Concepcin

Inicio o Estudio de oportunidad define el mbito y objetivos del proyecto se define la

funcionalidad y capacidades del producto

2. Elaboracin

Tanto la funcionalidad como el dominio del problema se estudian en profundidad se define una

arquitectura bsica y se planifica el proyecto considerando recursos disponibles

3. Construccin

El producto se desarrolla a travs de iteraciones donde cada iteracin involucra tareas de anlisis,

diseo e implementacin.

Las fases de estudio y anlisis slo dieron una arquitectura bsica que es aqu refinada de manera

incremental conforme se construye (se permiten cambios en la estructura)

Gran parte del trabajo es programacin y pruebas Se documenta tanto el sistema construido

como el manejo del mismo esta fase proporciona un producto construido junto con la

documentacin

4. Transicin

Se libera el producto y se entrega al usuario para un uso real Se incluyen tareas de marketing,

empaquetado atractivo, instalacin, configuracin, entrenamiento, soporte, mantenimiento, etc.

Los manuales de usuario se completan y refinan con la informacin anterior estas tareas se

realizan tambin en iteracionescada paso con las cuatro fases produce una generacin del

software. Amenos que el producto "muera", se desarrollar nuevamente repitiendo la misma

secuencia las fases de concepcin, elaboracin, construccin y transicin, pero con diversos

nfasis cada fase.


8/22

Pgina 8

1.4 DISEO DE ALTO NIVEL (HLD) Y BAJO NIVEL (LLD)

DISEO DE BAJO NIVEL

El diseo detallado es la actividad tcnica que sigue a la seleccin de la arquitectura. Es el ltimo

paso en la descomposicin orientada a objetos, en el que se llega a las unidades de programacin:

las clases de implementacin (representaciones simblicas del cdigo).

Su objetivo es dejar el proyecto preparado para la implementacin/codificacin:

parte de los resultados de la fase de arquitectura, describe en detalle cada una de las partes de la

solucin, verifica que se satisfacen los requisitos, y produce un diseo completo y listo para ser

programado.

Un diseo completo gua suficientemente la implementacin, de modo que la hace comprensible

y fcil de mantener, pero no necesariamente suprime toda creatividad en la implementacin.

Es decir, los programadores deben ser capaces de implementar un diseo detallado,

concentrndose en cuestiones de codificacin y dependientes de la plataforma tecnolgica

(lenguaje de programacin, sistema operativo, hardware, etc.).

Para que un diseo se pudiera implementar de forma no creativa, tendra que ser tan detallado

que no sera prctico.

DISEO DE ALTO NIVEL

El diseo de alto nivel puede consistir de diagramas que expresen aspectos de las diferentes vistas

de Kruchten, pero el diseo detallado es el cdigo fuente, punto. En software, nuestros planos

detallados es un documento tcnico llamado comnmente cdigo fuente, dichos planos de

nuestro producto son entregamos al constructor del producto: el compilador o traductor a cdigo

ejecutable.

El diseo de alto nivel establece el fondo, la forma y la interactividad del producto considerndolo

como un todo, como un conjunto de pantallas homogneas que constituyen la estructura o

arquitectura del producto multimedia sin entrar en el detalle de cada pantalla, ya que esto se har

en el Diseo Detallado.

El diseo de alto nivel establece la arquitectura general del producto por desarrollar.

Este diseo toma como punto de partida los contenidos y estrategias definidas en la etapa de

Diseo Instruccional y se enfoca en la descripcin de:

Estilos visuales generales del producto y de las pantallas que lo componen.

Elementos (texto, audio, imagen fija y en movimiento).

Caractersticas estructurales y grficas del producto.


9/22

Pgina 9

Navegacin entre las pantallas y otros aspectos relativos a la interactividad.

1.5 Comprensin de los requerimientos

Un requerimiento es una condicin o capacidad a la que el sistema (siendo construido) debe

conformar [ Rational ].

Un requerimiento de software puede ser definido como :

Una capacidad del software necesaria por el usuario para resolver un problema o alcanzar un

objetivo.

Una capacidad del software que debe ser reunida o poseda por un sistema o componente del

sistema para satisfacer un contrato, especificacin, estndar, u otra documentacin formal.

Los requerimientos de usuario representan el conjunto completo de resultados a ser obtenidosutilizando el sistema.

Los requerimientos de sistemas deben mostrar todo lo que el sistema debe hacer mas todas las

restricciones sobre la funcionalidad.

Los requerimientos forman un modelo completo, representando el sistema total a algn nivel de

abstraccin.

IDENTIFICACION DE LOS REQUERIMIENTOS

Los Requerimientos toman vida desde que realizamos nuestro primer encuentro de interlocucin

con usuarios o clientes.

Este puede desarrollarse utilizando cualquiera de una variedad de tcnicas como entrevistas

para intercambiar opiniones, brainstorming , prototipeo,cuestionarios, etc.

Cuando los requerimientos se logran redactar a un significativo nivel de detalle, tendremos listo

el documento denominado Especificacin de Requerimientos

ESPECIFICACION DE REQUERIMIENTOS

Un resultado primario de esta administracin es la Especificacin de Requerimientos, la cual

define y documenta en forma completa el comportamiento externo del sistema a ser construido.

Caracterizndose por :

Definidos sin ambiguedad

Son completos


10/22

Pgina 10

Tienen consistencia

Especifica el origen

Evita detalles de diseo

Estn enumerados

BENEFICIOS DE UNA BUENA ADMISTRACION DE REQUERIMIENTOS

Mejor control de proyectos complejos.

Mejora en lacalidad del software y en la satisfaccin del cliente.

Reduccin en los retrasos y en los costos del proyecto.

Mejora en la comunicacin del equipo.

Facilita laconformidad con estndares y regulaciones.

LOS PROBLEMAS DE LA ADMINISTRACION DE REQUERIMIENTOS

No son siempre obvios y tienen muchas fuentes.

No son siempre fciles de expresar en palabras.

Hay muchos tipos diferentes a distintos niveles de detalle.

El nmero puede llegar a ser inmanejable.

Estn relacionados a otros en una variedad de formas.

Hay muchos interesados y partes responsables.

Cambian.

Pueden ser sensibles al tiempo.

EL ALTO COSTO DE ERRORES EN LOS REQUERIMIENTOS

Hay fuertes evidencias que una efectiva administracin de requerimientos conducen los ahorros

del proyecto integral.

Las tres razones primarias para esto son :

Costos de reparar errores en los requerimientos superan en mas de 10 veces a otros errores.


11/22

Pgina 11

Errores de requerimientos comprenden encima del 40% de todos los errores de un proyecto de

software.

Pequeos reducciones en el nmero de errores de requerimientos rinden grandes dividendos al

evitar costos de re-trabajo y das de retraso.

1.6 CASOS DE USO

Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno

de sus servicios. Un caso de uso es iniciado por un actor. A partir de ese momento, ese actor, junto

con otros actores, intercambian datos o control con el sistema, participando de ese caso de uso.

1.6.1 INTRODUCCION

LOS CASOS DE USO SIRVEN:

Capturar los requerimientos del sistema

Para capturar el comportamiento deseado del sistema sin tener que especificar como se

implementa ese comportamiento Como medio de comprensin del sistema para desarrolladores,

usuarios finales y expertos del dominio Ayudan a validar la arquitectura y a verificar el sistema en

el transcurso del desarrollo de este Expresin de un caso de usos

Grficamente: los casos de uso se representan con un valo, con el nombre del caso en su interior.

GERUNDIO + OBJETO O ENTIDAD DEL SISTEMA QUE ES AFECTADO POR EL CASO

El nombre del caso siempre est expresado desde el punto de vista del actor y no

desde el punto de vista del sistema. Por eso el segundo caso de uso se llama Recibiendo

informacin de pedidos y no Generando informacin de pedidos


12/22

Pgina 12

1.6.2 Elementos de casos de uso (diagrama, Relaciones, Especificaciones, Identificacin

de Casos de Uso).

ACTORES

Un actor es una agrupacin uniforme de personas, sistemas o mquinas que interactan con el

sistema que estamos construyendo de la misma forma.

Los actores son externos al sistema que vamos a desarrollar.

Si bien en UML los actores siempre se representan con hombres de palo, a veces resulta til

representar a otros sistemas con alguna representacin ms clara.


13/22

Pgina 13

EJEMPLO DE UN ACTOR COMO SISTEMA

LOS CASOS DE USO TIENEN LAS SIGUIENTES CARACTERSTICAS:

1) Estn expresados desde el punto de vista del actor.

2) Se documentan con texto informal.

3) Describen tanto lo que hace el actor como lo que hace el sistema cuando interacta con l,

aunque el nfasis est puesto en la interaccin.

4) Son iniciados por un nico actor.

Descripcin de los Casos de Uso

Los casos de uso se documentan con texto informal. En general, se usa una lista numerada de los

pasos que sigue el actor para interactuar con el sistema. A continuacin se muestra una parte

simplificada de la

descripcin del caso de uso Ingresando Pedido.


14/22

Pgina 14

Alternativas

Durante la ejecucin de un caso de uso, suelen aparecer errores o excepciones. Por ejemplo,

mientras se ingresa un pedido, el cliente puede solicitar un producto que est discontinuado. El

sistema deber en este caso informar esta situacin al empleado que ingresa el pedido. Esas

desviaciones del curso normal del caso de uso se llaman alternativas.

Las alternativas tienen las siguientes caractersticas:

1) Representan un error o excepcin en el curso normal del caso de uso.

2) No tienen sentido por s mismas, fuera del contexto del caso de uso en el que ocurren.

las alternativas se documentan al final del caso de uso, la experiencia demuestra que

resulta til documentar los casos en tablas, mostrando el curso principal en la primera columna, y

las

alternativas en una segunda columna

Relaciones de Uso

Las caractersticas de las relaciones de uso son:

1) Aparecen como funcionalidad comn, luego de haber especificado varios casos de uso.

2) Los casos usados son casos de uso en s mismos.

3) El caso es usado siempre que el caso que lo usa es ejecutado. Esto marca la diferencia con las

extensiones, que son opcionales.


15/22

Pgina 15

1.7 Modelo del Dominio

Un modelo del dominio es una representacin de las clases conceptuales del mundo real, no de

componentes software. No se trata de un conjunto de diagramas que describen clases software, u

objetos software con responsabilidades. Tambin se les denomina modelos

conceptuales (trmino utilizado en la primera edicin del libro de Larman), modelo de objetos

del dominio y modelos de objetos de anlisis.

Un modelo del dominio se utiliza con frecuencia como fuente de inspiracin para el diseo de los

objetos software, y ser una entrada necesaria para varios de los siguientes artefactos que se

vern en este curso. El modelo del dominio muestra (a los modeladores) clases conceptuales

significativas en un dominio de] problema; es el artefacto ms importante que se crea durante el

anlisis orientado a objetos.

Modelos del Dominio

Los modelos de dominio pueden mostrar: Objetos del dominio o clases conceptuales. Asociaciones entre las clases conceptuales. Atributos de las clases conceptuales.


16/22

Pgina 16

Idea clave: Modelo del dominio un diccionario visual de abstracciones.

El modelo del ejemplo muestra una vista parcial, o abstraccin, e ignora detalles sin inters (para

el modelador).

Es fcil entender los distintos elementos y sus relaciones mediante este lenguaje visual, puesto

que un porcentaje significativo del cerebro toma parte en el proceso visualcualidad de los

humanos -.

Por esto el modelo del dominio podra considerarse como un diccionario visual de abstracciones

relevantes, vocabulario del dominio e informacin del dominio.

Los modelos del dominio no son modelos de componentes de software

Un modelo del dominio , es un representacin de las cosas del mundo real del dominio de inters,

no de componentes del software. Por lo tanto, los siguientes elementos no son adecuados en un

modelo de dominio:

Artefactos de software, como una ventana o base de datos, a menos que el dominio que se este

modelando sea de conceptos de software, como un modelo de interfaces de usuario grafica.

Responsabilidades o mtodos

Una clase conceptual es una idea, cosa u objeto. Ms formalmente, una clase conceptual

podra considerarse en trminos de un smbolo, intencin, y extensin.

Smbolo: palabras o imgenes que representan una clase conceptual.

Intencin: la definicin de una clase conceptual.

Extensin: el conjunto de ejemplos a los que se aplica la clase conceptual.

Por ejemplo considerar la clase conceptual para el evento de una transaccin de compra.


17/22

Pgina 17

Cuando se crea un modelo del dominio, normalmente, el smbolo y la vista intencional de la claseconceptual son los que tienen un mayor inters prctico.

La tarea central es identificar las clases conceptuales relacionadas con el escenario que se est

diseado.

Estrategias para identificar clases conceptuales:

Utilizar una lista de categoras clases conceptuales.

Identificacin de frases nominales.

Otra excelente tcnica para el modelado del dominio es el uso de patrones de anlisis, que son

modelos de dominios parciales existentes creados por expertos.


18/22

Pgina 18

Identificacin mediante frases nominales

Otra tcnica til (debido a su simplicidad) recomendada es el anlisis lingstico: identificar los

nombres y frases nominales en las descripciones textuales de un dominio, y considerarlos como

clases conceptuales o atributos candidatos.

Se debe tener cuidado con este mtodo; no es posible realizar una correspondencia mecnica de

nombres a clases , y las palabras en lenguaje natural son ambiguas.


19/22

Pgina 19

1.7.2 Aadir asociaciones

Se representa como una lnea entre clases con un nombre de asociacin. La asociacin esinherentemente bidireccional.

Comience la inclusin de asociaciones utilizando la siguiente tabla


20/22

Pgina 20

Localizacin de las Asociaciones

Gua para las Asociaciones

Centrase en aquellas asociaciones para las que se necesita conservar el conocimiento de la

relacin durante el tiempo.

Es ms importante identificar clases conceptuales que asociaciones.


21/22

Pgina 21

Demasiadas asociaciones tienden a confundir el modelo.

Evite mostrar asociaciones redundantes o derivadas

Asociaciones en detalle

Roles

Los extremos de las asociaciones se denominan roles. Pueden tener opcionalmente Nombre,

Expresiones de Multiplicidad, Navegabilidad.

Multiplicidad

Define cuantas instancias de una clase A pueden asociarse con una instancia de la clase B.

* cero o ms muchos

1..* uno o ms

1..40 de uno a 40

5 exactamente 5

3,5,8 exactamente 3,5,8

Asignacin de nombres a las asociaciones

Deben comenzar con mayscula.

La direccin por defecto para la lectura de los nombres de la asociacin es de izquierda a derecha

o de arriba a bajo.

Asociacin e Implementacin

Durante el modelo de dominio, una asociacin, es una manifestacin de que una relacin es

significativa en un sentido puramente conceptualen el mundo real -. Se pueden definir

asociaciones que no existan en la implementacin.


22/22

Pgina 22

1.7.3 Aadir atributos

Atributo es el valor de datos lgico de un objeto.

Incluir los siguientes atributos en un modelo del dominio: aquellas para que los requisitos (ej:

casos de uso) sugieran o impliquen una necesidad de registrar informacin.

Mantenga atributos simples

Intuitivamente, la mayora de los atributos simples son los que, a menudo, se conocen como los

tipos de datos primitivos, como los nmeros. El tipo de un atributo, normalmente no debera ser

un concepto de dominio complejo, como Venta o Aeropuerto.

Los atributos en un modelo de dominio deberan ser preferiblemente, atributos simples o tipos de

datos (boolean, fecha, nmero, string, hora).

Se recomienda que se relacionen las clases conceptuales por asociaciones no con atributos

En caso de duda, defina algo como una clase conceptual aparte en lugar de como atributo.

Qué es Análisis y Diseño Orientado a Objetos.docx

Documents

Transcript of Qué es Análisis y Diseño Orientado a Objetos.docx