Qué es Análisis y Diseño Orientado a Objetos.docx
-
Upload
itzel-salinas-rodriguez -
Category
Documents
-
view
216 -
download
0
Transcript of 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
-
8/13/2019 Qu es Anlisis y Diseo Orientado a Objetos.docx
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.
-
8/13/2019 Qu es Anlisis y Diseo Orientado a Objetos.docx
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.
-
8/13/2019 Qu es Anlisis y Diseo Orientado a Objetos.docx
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.
-
8/13/2019 Qu es Anlisis y Diseo Orientado a Objetos.docx
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.
-
8/13/2019 Qu es Anlisis y Diseo Orientado a Objetos.docx
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
-
8/13/2019 Qu es Anlisis y Diseo Orientado a Objetos.docx
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/13/2019 Qu es Anlisis y Diseo Orientado a Objetos.docx
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.
-
8/13/2019 Qu es Anlisis y Diseo Orientado a Objetos.docx
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
-
8/13/2019 Qu es Anlisis y Diseo Orientado a Objetos.docx
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.
-
8/13/2019 Qu es Anlisis y Diseo Orientado a Objetos.docx
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
-
8/13/2019 Qu es Anlisis y Diseo Orientado a Objetos.docx
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.
-
8/13/2019 Qu es Anlisis y Diseo Orientado a Objetos.docx
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.
-
8/13/2019 Qu es Anlisis y Diseo Orientado a Objetos.docx
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.
-
8/13/2019 Qu es Anlisis y Diseo Orientado a Objetos.docx
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.
-
8/13/2019 Qu es Anlisis y Diseo Orientado a Objetos.docx
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.
-
8/13/2019 Qu es Anlisis y Diseo Orientado a Objetos.docx
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.
-
8/13/2019 Qu es Anlisis y Diseo Orientado a Objetos.docx
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.
-
8/13/2019 Qu es Anlisis y Diseo Orientado a Objetos.docx
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
-
8/13/2019 Qu es Anlisis y Diseo Orientado a Objetos.docx
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.
-
8/13/2019 Qu es Anlisis y Diseo Orientado a Objetos.docx
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.
-
8/13/2019 Qu es Anlisis y Diseo Orientado a Objetos.docx
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.