Analisis y Diseño Orientado a Objetos

5/23/2018 Analisis y Dise o Orientado a Objetos

Universidad Tecnolgica Nacional

Facultad Regional Resistencia

Diseo de Sistemas

Profesor:A.U.S. Gustavo Marcelo Torossi


Anlisis y Dise#o Universidad Tecnol&gica NacionalOrientado a Objetos F.R.R.

Prof. A.U.S. Gustavo Torossi PRELIMINAR Pgina 2 de 61

MODELADO Y DISE(O ORIENTADO A OBJETOS

Tabla de contenidos

Unidad 16: Introduccin a la Orientacin a Objetos ...................................................... 6

16.1 Conceptos fundamentales.................................................................................. 6Presentacin del m#todo........................................................................................ 6

Beneficios de las t#cnicas O.O. ............................................................................. 6

Tres enfoques de organizacin para comprender el mundo.................................... 6

16.2 Concepto de Objeto y Clase. ............................................................................. 7

Objeto................................................................................................................... 7

Clase..................................................................................................................... 7

Comunicacin por mensajes.................................................................................. 7

16.3 Principios fundamentales................................................................................... 7

Abstraccin........................................................................................................... 7

Encapsulamiento................................................................................................... 7

Herencia ............................................................................................................... 7

Polimorfismo ........................................................................................................ 716.4 Conceptos Adicionales................................................................ ...................... 8

Agregacin ........................................................................................................... 8

Concurrencia......................................................................................................... 8

Persistencia........................................................................................................... 8

Visibilidad ............................................................................................................ 8

16.5 Modelos utilizados. ........................................................................................... 8

Modelo de Estructura de Objetos .......................................................................... 8

Modelo de Secuencias de Transacciones ............................................................... 8

Diagramas de Interaccin de Objetos .................................................................... 8

Diagramas de Flujo de Actividad .......................................................................... 8

Modelo de ciclo de vida de objetos........................................................................ 8

Modelo global del sistema..................................................................................... 9Unidad 17: Modelo de Estructura de Objetos (OSM).................................................. 10

17.1 Conceptos y propsito del modelo de estructura de objetos ............................. 10

17.2 Componentes del modelo de estructura de objetos........................................... 10

Objetos entidad ................................................................................................... 11

Objetos Interface................................................................................................. 11

Objetos de control ............................................................................................... 11

Clases abstractas y concretas............................................................................... 11

Operaciones ........................................................................................................ 12

Atributos............................................................................................................. 12

Restricciones....................................................................................................... 13

Relaciones Est%ticas............................................................................................ 13Herencia ............................................................................................................. 14

Ejemplo .......................................................................................................... 15

Agregacin ......................................................................................................... 15

Ejemplo .......................................................................................................... 16

Comunicacin por mensajes................................................................................ 16

T#cnicas Avanzadas de Modelado de Estructura de Objetos................................ 16

Unidad 18: Modelado de Procesos de Negocios y Secuencias de Transacciones.......... 18

18.1 Conceptos y propsito del modelo de p. de negocios y sec. de trans. ............... 18




Proceso de Negocio............................................................................................. 18

Como identificar y definir procesos de negocio? ................................................. 19

Secuencia de Transacciones ................................................................................ 19

Como identificar y definir secuencias de transacciones?...................................... 19

18.2 Componentes y Herramientas de modelado de procesos de negocios y

secuencias de transacciones .................................................................................... 2018.3 Diagrama de Secuencia de Transacciones (TSD)............................................. 20

Evento............................................................................................................. 21

Comunicacin entre Actor y Sec.Trans................................................................ 21

Secuencia com'n ............................................................................................ 21

Descripcin Textual: componentes...................................................................... 21

3) Camino est%ndar y alternativo..................................................................... 21

4) Actores ........................................................................................................... 22

Subdivisin de procesos de negocios................................................................... 22

Unidad 19: Modelado de Interaccion de Objetos......................................................... 23

19.1 Conceptos y propsito del modelado de interaccin de objetos....................... 23

Utilizacin del modelado de interaccin de objetos ............................................. 23

19.2 Herramientas de modelado. ............................................................................. 24Diagrama de interaccin de objetos para un proceso de negocios ........................ 24

Diagrama de interaccin de objetos para una secuencia de transacciones............. 25

Elementos ....................................................................................................... 25

Casos Especiales ............................................................................................. 26

Diagrama de flujo de actividad............................................................................ 26

Simbolog)a de los diagramas de flujo de actividad .......................................... 27

Observaciones................................................................................................. 28

19.3 T#cnicas avanzadas de modelado. ................................................................... 28

Usando AFD para modelar operaciones del sistema ............................................ 28

Diagramas de interaccin de objetos, secuencias de transacciones y escenarios... 28

Unidad 20: Modelo de Ciclo de Vida de Objetos ........................................................ 29

20.1 Conceptos y propsito del modelo de ciclo de vida de objetos. ....................... 29Utilizacin del modelo de ciclo de vida de objetos .............................................. 29

20.2 Herramientas de modelado. Diagrama de ciclo de vida de objetos. .................. 29

Componentes del OLD........................................................................................ 30

Ejemplo: PILA.................................................................................................... 31

20.3 T#cnicas avanzadas de modelado. ................................................................... 31

Unidad 21: Modelo Global del Sistema....................................................................... 32

21.1 Conceptos y propsito del modelo del modelo global del sistema. .................. 32

Conceptos............................................................................................................... 32

El espacio del problema y sus componentes ........................................................ 32

Definicin del alcance de un subsistema ............................................................. 33

Servicios............................................................................................................. 33

Particiones verticales y horizontales.................................................................... 33

21.2 Diagrama de Modelo Global del Sistema......................................................... 34

Componentes del diagrama ................................................................................. 34

21.3 Conceptos avanzados ...................................................................................... 35

Uso de Clases de Objetos para encapsular subsistemas........................................ 35

Unidad 22: Ciclo de Desarrollo Orientado a Objetos................................................... 36

22.1 Fases del ciclo de desarrollo O.O. ................................................................... 36

22.2 Uso de los distintos modelos. .......................................................................... 37

An%lisis del Negocio ........................................................................................... 37




An%lisis de Requerimientos................................................................................. 37

Dise+o Lgico..................................................................................................... 38

Dise+o F)sico ...................................................................................................... 38

El rol de las versiones en un proceso de desarrollo aditivo .................................. 39

22.3 Arquitectura de Seis Componentes.................................................................. 39

Unidad 23: An%lisis del Negocio................................................................................. 4023.1 Actividades del An%lisis del Negocio .............................................................. 40

23.2 Modelado de Objetos del Negocio................................................................... 40

Pasos en el modelado de objetos de negocio........................................................ 41

Qu# modelar?...................................................................................................... 41

23.3 Modelado de Ciclo de Vida de Objetos ........................................................... 41

Cuando modelar ciclos de vida? .......................................................................... 41

Como modelar ciclos de vida de objetos.............................................................. 41

23.4 Modelado de Procesos de Negocio. ................................................................. 42

Pasos del modelado de procesos de negocio ........................................................ 42

Identificacin de procesos de negocio ................................................................. 42

Como describir procesos de negocio ................................................................... 42

23.5 Chequeo del modelo de an%lisis del negocio.................................................... 43Unidad 24: An%lisis de Requerimientos ...................................................................... 44

Actividades del An%lisis de Requerimientos........................................................ 44

24.1 Definicin de secuencia de transacciones. ....................................................... 45

Identificacin de secuencias de transacciones...................................................... 45

Relacin entre actores y eventos externos............................................................ 45

Uso de Diagramas de Secuencias de Transacciones............................................. 45

Alcance de una secuencia de transacciones ......................................................... 46

24.2 Descripcin de caminos est%ndar y alternativos ............................................... 46

Identificacin y definicin de secuencias comunes.............................................. 47

Jerarqu)as de actores ........................................................................................... 47

Modelando interfaces de usuario e interfaces externas......................................... 47

24.3 Expandiendo el modelo de estructura de objetos.............................................. 47Pasos en el modelado de estructura de objetos para el an%lisis de requerimientos 47

Definicin de ciclos de vida de objetos................................................................ 48

24.4 Uso de diagramas de modelo global ................................................................ 48

24.4 Chequeo del modelo de an%lisis de requerimientos.......................................... 48

Unidad 25: Dise+o lgico ........................................................................................... 49

25.1 Relaciones entre el dise+o lgico y f)sico ........................................................ 49

25.2 Actividades realizadas durante el dise+o lgico............................................... 49

25.3 Identificacin de Objetos de interface y de Control ......................................... 49

Como identificar objetos interfaz ........................................................................ 49

Como identificar objetos de control..................................................................... 50

Asociaciones posibles entre los distintos tipos de objetos .................................... 51

25.4 Identificando y definiendo operaciones ........................................................... 52

Notacin de punto............................................................................................... 52

Como identificar operaciones.............................................................................. 52

M#todo de identificacin 1: considerando roles y responsabilidades para cada clase

de objetos............................................................................................................ 53

M#todo de identificacin 2: Interaccin de objetos requerida para soportar cada

secuencia de transacciones .................................................................................. 53

M#todo de identificacin 3: Analizando ciclos de vida de objetos ....................... 54

Especificacin de la sem%ntica y sintaxis de las operaciones ............................... 54




Operaciones de clase........................................................................................... 55

Herencia de operaciones...................................................................................... 55

Operaciones concretas, abstractas, y templados............................................... 55

Redefiniendo operaciones heredadas ............................................................... 55

25.5 Redefiniendo el modelo de estructura de objetos ............................................. 55

Adicin y remocin de clases de objetos ............................................................. 55Identificacin de Atributos.................................................................................. 56

Definicin de persistencia de atributos ................................................................ 56

25.8 Subsistemas .................................................................................................... 56

25.9 Chequeo del modelo de dise+o lgico ............................................................. 56

Unidad 26: Dise+o F)sico............................................................................................ 57

26.1 Arquitectura del sistema. ................................................................................. 57

26.2 Componente Dominio de Problema (PDC)...................................................... 59

26.3 Componente de Interaccin Humana (HIC)..................................................... 59

26.4 Componente de Administracin de Datos (DMC)............................................ 59

Arquitectura del DMC......................................................................................... 60

Dise+o de base de datos relacional ...................................................................... 60

26.5 Componente de Interface Externa (EIC).......................................................... 6126.6 Componente de Administracin de Tareas (TMC)........................................... 61

26.7 Componente de Servicios de Utiler)a (USC).................................................... 61

26.8 Chequeo del modelo de dise+o f)sico............................................................... 61




Unidad 16: Introducci#n a la Orientaci#n a Objetos

16.1 Conceptos fundamentales.

Presentaci#n del m&todo

Beneficios de las t&cnicas O.O.

1) Reusabilidad del software2) Mayor flexibilidad para realizar mantenimiento y modificaciones del software3) Disminuye el gap sem%ntico proveyendo una representacin consistente en todo el

ciclo de vida

4) Mejor interaccin entre el usuario/analista/dise+ador.5) M%s apropiado para abordar problemas m%s complejos.

Tres enfoques de organizaci#n para comprender el mundo

1) Diferenciacin de la experiencia en Objetos y Atributos

MAINSTREAM

OBJECTS

Combina una s)ntesis de las principales

t#cnicas y enfoques O.O.

Fuentes

Principales

Rumbaugh / Coad / Yourdon:- Estructura de Objetos- Ciclo de Vida

Jacobson- Enfoque Use Case (secuencia de

trans, para capturar requerimientos

del sistema)

R.Wirfs-Brock- Responsability-Driven model (como

estructurar la funcionalidad de un

sistema O.O




2) Distincin entre el todo y sus partes3) Formacin y distincin de clases de objetos.

16.2 Concepto de Objeto y Clase.

Objeto

Definicin 1:Un objeto es algo real o abstracto acerca del cual almacenamos datos y

m#todos que manipulan dichos datos (Mart)n/Odell)

Definicin 2:Encapsulado de datos, operacionesque tratan dichos datos, y que observa

un estado interno, que posee identidad(se distingue por su existencia misma y no por

sus atributos).

Cada objeto es una instanciade la clase a la que pertenece.

Clase

Una clase es un grupo de objetos conpropiedades(atributos) similares, comportamiento

com'n (operaciones), relaciones comunes entre objetos, y sem#ntica com'n

(Raumbaugh).

Comunicaci#n por mensajes

Los objetos de un sistema se comunican entre si a trav#s de mensajes. El mensaje es

enviado por un objeto emisory recibido por un objeto destino o receptor. Un mensaje

invoca una o m%s operaciones en el objeto receptor.

16.3 Principios fundamentales

Abstracci#n

Encapsulamiento

Mecanismo que permite ocultar los detalles de implementacin de un objeto. Permite

empaquetar en una unidad los datos y las funciones que operan sobre dichos datos.

Herencia

Relacin entre clases de objetos que permite incluir (rehusar) los atributos y operaciones

definidas en otra clase m%s general de la cual se hereda o deriva.

Polimorfismo

La misma operacin es resuelta de diferente forma seg'n el objeto que recibe el

mensaje.




16.4 Conceptos Adicionales

Agregaci#n

Composicin de un objeto por otros. Es una relacin m%s d#bil que la que existe entre el

atributo y el objeto al cual pertenece, y m%s fuerte que una asociacin.

Concurrencia

Propiedad que distingue un objeto activode otro inactivo. (Booch)

Persistencia

Es la propiedad de un objeto cuya existencia trasciende el tiempo y/o el espacio (ej. el

objeto continua existiendo luego de que su creador deja de existir / la ubicacin de un

objeto se mueve a un espacio de direcciones diferente de aquella donde fue creada).

Visibilidad

capacidad de restringir el acceso a atributos y servicios de un objeto. Particularmente

importante en el dise+o e implementacin. (ej. C++: p'blico / protegido / privado)

16.5 Modelos utilizados.

Modelo de Estructura de Objetos

El modelo de estructura de Objetos (OSM) es el modelo central. Contiene las clases de

objetos requeridas para construir la aplicacin y las relaciones entre ellas. Se construye

a trav#s de un proceso aditivo durante todo el ciclo de desarrollo del sistema.

Modelo de Secuencias de Transacciones

El modelo de procesos de negocios(BPM) describe los procesos que se llevan a cabo en

la organizacin. Se lo utiliza para analizar la organizacin y comprender sus procesos,

parte de los cuales (o todos), ser%n soportados por el sistema a desarrollar. El modelo de

secuencia de transacciones(TSM) parte de la especificacin de alto nivel del BPM y lo

traslada en requerimientos para la aplicacin. El TSM se corresponde conceptualmente

con lo USE-CASEs de Jacobson (OOSE).

Diagramas de Interacci#n de Objetos

Los diagramas de interaccin de objetos muestran las interacciones entre objetos

requeridas para proveer al usuario los servicios descriptos en el TSM.

Diagramas de Flujo de Actividad

Los diagramas de flujo de actividad son utilizados para analizar y presentar flujos de

actividad complejos en los procesos de negocio y en las secuencias de transacciones

(secuencias, iteraciones, y decisiones).

Modelo de ciclo de vida de objetos

El modelo de ciclo de vida de objetoses utilizado para describir como un objeto cambia

de estados en el tiempo y que eventos producen dichos cambios de estado.




Modelo global del sistema

El modelo global del sistema es utilizado para dividir el sistema en unidades de dise+o

manejables. Es una herramienta para manejar la complejidad de desarrollo de grandes

sistemas. Especifica la interfaces entre las unidades de dise+o.

Modelo Estructural

(Est%tico)

Modelo de Comportamiento(Din%mico)

Modelo Funcional

Modelo de Estructura

de Objetos (OSM)

Diagrama de Ciclo de Vida de

Objetos (OLD)

Diagrama de Interaccin de

Objetos (OID)

Modelo de Procesos de

Negocios (BPM)

Modelo de Secuencia deTransacciones (TSM)




Unidad 17: Modelo de Estructura de Objetos (OSM)

17.1 Conceptos y prop#sito del modelo de estructura de objetos

El OSM es el modelo fundamental que provee un medio uniforme para modelar el

sistema desde la captura de requerimientos en la etapa inicial del an%lisis hasta la

implementacin, atravesando todo el ciclo de desarrollo del sistema.

Este modelo identifica :

- las clases de objetos en la aplicacin- como las clases de objetos se asocian unas con otras- como se comunican los objetos- los detalles de cada clase de objetos, incluyendo atributos y operaciones

Durante el proceso de an%lisis y dise+o, el OSM es definido en sucesivos niveles

incrementales de detalle, hasta que el nivel necesario para la implementacin es

alcanzado.

Todos los dem%s modelos capturan detalles que alimentanes modelo.El desarrollo de OSM es un proceso aditivo, diferenci%ndose esto del enfoque

transformacionalcaracter)stico de otros m#todos como el estructurado, donde los DFD

del an%lisis son transformados en diagramas de estructura durante el dise+o, con los

consiguientes problemas que esto acarrea.

Durante el ciclo de desarrollo se aportan los siguientes elementos al modelo:

- An#lisis del Negocio: se reconocen objetos claves del negocio y generan lasabstracciones en las clases apropiadas (objetos entidad).

- An#lisis de Requerimientos:se identifican asociaciones estructurales entre objetos ynuevas clases (entidad).

- Dise%o lgico: Se incorporan todas las clases necesarias para la aplicacin

incluyendo los objetos de interfaz y de control.- Dise%o F(sico:se incorporan todos los detalles remanentes para la implementacin

f)sica de cada clase de objetos.

17.2 Componentes del modelo de estructura de objetos.

El componente b%sico del OSM es la clase de objetos.

Se distinguen tres tipos de clases:

- Objetos Entidad- Objetos de Interfaz- Objetos de Control.Para cada clase identificada se describen:

- Operaciones- Atributos- Restricciones

Adicionalmente el OSM describe las asociacionesentre objetos o clases de objetos. Se

distinguen los siguientes tipos de asociaciones:

- Relaciones Est%ticas- Herencia




- Agregacin- Comunicacin por mensajes

Objetos entidad

Representan algo real o abstracto sobre el cual el sistema necesita almacenar datos.

Representan la memoria esencial del negocio. Los objetos del negocio (business

objects) son normalmente objetos entidad. Ejemplos de objetos entidad pueden ser

empleado, alumno, etc.

Se representan en el diagrama de estructura de objetos con el siguiente s)mbolo:

Objetos Interface

Representan lo objetos t#cnicos requeridos para vincular la aplicacin con el entorno.

Representan el v)nculo a trav#s del cual el sistema recibe o suministra datos e

informacin al entorno. T)picamente incluyen interfaces con el usuario (pantallas,

reportes, etc.) e interfaces con otras aplicaciones.


Objetos de control

Contienen comportamiento que no pertenece naturalmente ni a objetos entidad ni de

interfaz. Son normalmente objetos transitorios, como ser un controlador de reportes.


Clases abstractas y concretas

Una clase de la cual pueden generarse instancias particulares (objetos), se denomina

clase concreta.

Una clase abstractaes aquella que no instancias (objetos) propias. Las clases abstractas

son un poderoso mecanismo conceptual para definir estructuras comunes de atributos,

operaciones, y restricciones, reutilizadas a trav#s de la herencia por m'ltiples clases

concretas.

Em leado

Consulta X

Control X




En el diagrama de estructura de objetos una clase abstracta se representa con un

rect%ngulo punteado.

Operaciones

Una operacin define un servicio ofrecido por un objeto junto con la informacin que

debe suministrarse cuando es invocado (nombre, argumentos de entrada/salida).

Tambi#n puede contener una especificacin de m*todo, el cual especifica una

implementacin para la operacin.

Notacin:Durante la etapa de An%lisis o Dise+o lgico pueden utilizarse t)picamente

texto libre o pseudocdigo. Durante el Dise+o f)sico dichas especificaciones son

trasladadas en un lenguaje de programacin espec)fico como ser C++, Java, Visual

Basic, etc.

Algunas operaciones pueden asumirse que existen para cada clase de objetos sin

identificarlas formalmente. Estas son llamadas operaciones impl(citas. Las operaciones

impl)citas m%s importantes son Crear, Destruir, Leer, y Actualizar. Una operacin

impl)cita debe ser formalmente definida cuando sus pre y post condiciones no sean

triviales.

La identificacin y especificacin de operaciones es una tarea clave durante el Dise+o

Lgico.

AtributosSon valores de datos asociados a los objetos de una clase al cual describen.

Est%n fuertemente asociados con la clase de objetos que los contienen, de tal forma que

no tienen existencia independiente o identidad de objeto.

La decisin de cuando un )tem debe considerarse como atributo o como clase var)a de

sistema en sistema, dependiendo de su sem%ntica en el dominio de problema. Lo que en

un sistema se modela como atributo en otro puede modelarse como una clase.

Cada atributo identificado debe ser atmicoen el sentido de que debe ser tratado como

una unidad. En tal caso puede ser un valor simple o grupo de valores tratados siempre

como unidad (ej. direccin).

Debe notarse que las clases no se modelan en formas normales. La decisin sobre la

estructura de datos subyacente a utilizar se difiere hasta el Dise+o F)sico.

Los atributos pueden basarse en definiciones de tipos de atributos, lo cual provee una

definicin est%ndar sobre formato, longitud y dominio de valores para atributos del

mismo tipo.

Clase Abstracta




Restricciones

Las restricciones pueden especificarse sobre los valores que un atributo o relacin

pueden tomar.

La implementacin de las restricciones puede realizarse de diferentes formas:

- reglas de validacin durante los procesos de entrada de datos (user inputs)

- database-level triggers- lgica de control contenida en una o m%s operaciones.

Relaciones Est(ticas

Las relaciones est%ticas describen como los objetos se asocian unos con otros en la

misma forma que en el modelo entidad-relacin. Identifican as)mismo dependencias

entre objetos, cuando un objeto requiere de la existencia de otro ya sea de la misma

clase o de otra.

Las relaciones est%ticas se establecen usualmente entre objetos de tipo Entidad.

Al igual que los atributos, las relaciones modelan informacin sobre un objeto (cosas

que un objeto debe conocer sobre s)mismo). Estas son propiedades de un objeto. Losatributos son valores de datos. Las relaciones son valores que referencian otros objetos.

Una relacin est%tica se representa en el diagrama de estructura de objetos como una

l)nea slida entre las clases de objetos, con s)mbolos de cardinalidad en sus extremos.

Las relaciones pueden etiquetarse para identificar el propsito de la asociacin. El

dise+ador puede optar por:

- un nombre para cada direccin de la relacin- un nombre para una direccin de la relacin- un solo nombre que representa ambas direcciones de la relacin- sin nombre

Por cuestiones de simplicidad, las relaciones son modeladas como binarias, es decir,

solo dos clases de objetos, no necesariamente distintas, participan en la relacin.

Es posible que entre el mismo par de clases exista m%s de una relacin.

La cardinalidad identifica el n'mero m%ximo y m)nimo de instancias de una clase

(objetos) que participan en una relacin dada, en el mismo sentido que lo hacen en el

modelo entidad-relacin.

En el diagrama de estructura de objetos utilizaremos la notacin de pata-de-gallo para

especificar cardinalidades, aunque puede utilizarse otras como ser pares ordenados,

flechas (Bachmann), etc.

Pueden observase las siguientes cardinalidades:

Mnimo 1 - M#ximo 1.

Mnimo 0 - M#ximo 1.




Mnimo 1 - M#ximo N.

Mnimo 0 - M#ximo N.

Ejemplo:

Herencia

La herencia es el mecanismo a trav#s del cual los atributos, operaciones, y restricciones

definidas para una clase, denominada superclase, pueden ser heredados (reutilizados)

por otras clase denominadassubclases.

La herencia utiliza el principio ,es un tipo de ...-.

Una subclase puede redefinir operaciones heredadas. Adicionalmente, una subclase

puede definir nuevos atributos y operaciones.

Se distingue entre herencia simple y m'ltiple. La herencia simple se da cuando un

subclase hereda de una 'nica superclase. En el caso de la herencia m'ltiple, una

subclase puede heredar de varias superclases. La decisin de soportar herencia simple o

m'ltiple ha dado lugar a largos debates conceptuales y metodolgicos.En el actual enfoque, Mainstream Objects de Ed.Yourdon, solo se soporta Herencia

Simple.

En el diagrama de estructura de objetos, la relacin de herencia se representa de la

siguiente manera:

Subclase 1

Superclase

IH

Subclase 2

Colectivo Chofer

Es conducido

conduce




Ejemplo

Agregaci#n

La agregacin es un tipo de asociacin fuerte, donde los objetos de una clase se

componen de objetos de otra(s) clase(s). Se diferencia de las relaciones est%ticas en la

fuerza sem#nticadel v)nculo. En una relacin de agregacin un objeto componeotro.

En la relacin est%tica existe un v)nculo pero no una composicin.

La agregacin es la aplicacin del principio .el todo y sus partes .../.

En el diagrama de estructura de objetos, la relacin de agregacin se representa de la

siguiente manera:

Automvil

Veh)culo

IH

Motocicleta

Componente 1

Agregado

A

Componente 3Componente 2




Ejemplo

Comunicaci#n por mensajes

Las asociaciones por comunicacin pueden utilizarse para mostrar que objetos de una

clase se comunican con objetos de otra clase o de la misma.

Una asociacin por comunicacin corresponde al conjunto de mensajes que son

enviados por los objetos de una clase a los objetos de otra clase o de la misma.

T)picamente, la asociacin por comunicacin es la 'nica asociacin existente entre

objetos de los tres diferentes tipos.

En el diagrama de estructura de objetos, la asociacin por comunicacin se representa

de la siguiente manera:

T&cnicas Avanzadas de Modelado de Estructura de Objetos

Visibilidad:define que objetos puede acceder y utilizar los atributos y operaciones deun objeto dado.

P'blico : todos

Protegido : solo desde el objeto mismo y operaciones definidas en subclases

Privado : solo desde el objeto mismo

Cuadro

Bicicleta

A

ManubrioRueda

Emisor Receptor




Atributos identificadores: son atributos o grupos de atributos que identifican

un)vocamente un objeto de una clase. Se corresponde con el concepto de claves del

modelo E-R.

Atributos derivados:son atributos cuyo valor puede obtenerse a partir de los valores de

otros atributos.

Relaciones derivadas:relaciones transitivas que se derivan de otras relaciones est%ticas.

En el diagrama de estructura de objetos las relaciones derivadas se representan de la

siguiente manera:

Relaciones Ordenadas:los objetos del extremo .muchos/de una relacin se presentan

en forma ordenada. Es particularmente 'til para especificar que los objetos componentes

de un agregado est%n ordenados. Por ordenado, entendemos que los objetoscomponentes ser%n accedidos en una secuencia espec)fica predefinida.

En el diagrama de estructura de objetos las relaciones ordenadas se representan de la

siguiente manera:

Atributos y operaciones de clase:definen el comportamiento de la clase misma m%s all%

del comportamiento de sus instancias.Los atributos de clase son utilizados para registrar datos comunes a todos los objetos

(instancias) de una misma clase.

Las operaciones de clase act'an sobre la clase misma como un objeto. El caso t)pico son

las operaciones Crear y Destruir.

A{ordenado}




Unidad 18: Modelado de Procesos de Negocios y Secuencias

de Transacciones.

18.1 Conceptos y prop#sito del modelo de p. de negocios y sec. de trans.

Los requerimientos para una aplicacin de negocios deben basarse en las actuales

actividades del negocio, que la aplicacin deber%soportar.

El Modelo de Procesos de Negocios (BPM) es usado durante el an%lisis del negocio

(an%lisis del sistema actual) y provee un medio para describir el negocio.

El Modelo de Secuencia de Transacciones (TSM) es usado durante el an%lisis de

requerimientos del negocio y provee un medio para describir la funcionalidadrequerida

de la aplicaciones para soportar los procesos de negocios.

El enfoque en los procesos de negocio durante el an%lisis del negocio provee el punto departida para determinar qu#se requiere de la aplicacin.

Durante el an%lisis de requerimientos decidimos qu#parte de los procesos de negocio

deben computarizarse y describimos dichos requerimientos usando una o m%s

secuencias de transaccin (determinacin de las fronteras de automatizacin).

Las secuencias de transacciones modelan que es lo que el usuario requiere de la

aplicacin (su contenido funcional).

Las secuencias de transacciones proveen la navegabilidad desde lo requerimientos del

usuario a los objetos y operaciones que implementan dicha funcionalidad.

Las secuencias de transacciones proveen tambi#n un medio adecuado para comunicarse

con el usuario en un leguaje y nivel de abstraccin que #l pueda comprender con

facilidad.

Como parte del proceso de Dise+o Lgico, las secuencias de transacciones son

analizadas para identificar como los objetos y sus operaciones proveen la funcionalidad

requerida por una secuencia de transacciones.

Posteriormente, durante el proceso de testeo de la aplicacin, sirven de base para definir

casos de testeos.

Proceso de Negocio

Un proceso de negocios es una coleccin de actividades que toman uno o m%s tipos de

entrada, y crea una salida de valor para el cliente1.

Un proceso de negocios describe desde el comienzo al fin la secuencia de eventos

requeridos para producir un resultado de negocio significativo.

El cliente puede ser externo o interno a la organizacin.

Los procesos de negocio t)picamente atraviesan los l)mites de la organizacin y de sus

departamentos internos, evitando la cl%sica visin de compartimentos estancos. Por este

motivo, cualquier modificacin dr%stica a un proceso de negocio implica un cambio en

la estructura organizacional.

1Definicin seg'n Hammer y Champy




Como identificar y definir procesos de negocio?

1) Se identifican los productos/servicios significantes de los que es responsable elnegocio y se asocia cada uno de ellos a uno o m%s procesos de negocios.

2) Se identifican las entradas y eventos disparadores que inician cada proceso denegocio y se da un nombre a cada PN.

3) Cada PN se describe especificando las actividades de alto nivel que se requierenpara producir los productos y servicios.

Secuencia de Transacciones

El concepto desecuencia de transaccioneses muy similar al concepto de Caso de Uso

introducido por Jacobson en su metodolog)a OOSE y de amplia difusin actualmente.

Una secuencia de transacciones es conceptualmente similar a un proceso de negocio. La

diferencia radica en su alcance. El proceso de negocio se utiliza para comprender y

modelar el funcionamiento de la empresa (negocio). Las secuencias de transacciones se

utilizan para modelar los requerimientos funcionales de la aplicacin que soportar%

determinados procesos de negocios.

Los procesos de negocio son trasladados en secuencias de transacciones durante el

an%lisis de requerimientos.

El alcance de una secuencia de transacciones es el mismo de un proceso de negocios o

de un subproceso muy significativo.

Una secuencia de transacciones puede implicar m%s de un usuario y funcin y puede

extenderse en el tiempo, esto es no tener resolucin inmediata.

El proceso de identificar requerimientos del usuario y secuencias de transacciones

puede asistirse con la prototipacin de interfaces.

Como identificar y definir secuencias de transacciones?

1) Identificacin a trav*s de actores1.1Identificar los actores que se comunicar%n con el sistema.

Entradas y/o Eventos

Salidas Menores

Evento ProductoProceso de Negocios




1.2Para cada actor considerar:1.2.1 Cuales son las principales tareas del actor1.2.2 Qu#accesos (lectura o escritura) requiere el actor del sistema1.2.3 Cuando el actor informar%al sistema acerca de cambios fuera del sistema1.2.4 Cuando el actor ser%informado de cambios a trav#s del sistema

2) Identificacin a trav*s de eventosConsiste en identificar a que eventos externos o temporales debe ser capaz de responder

el sistema:

2.1 Confeccionar la lista de eventos.

2.2 Asociar una secuencia de transacciones para cada evento identificada.

18.2 Componentes y Herramientas de modelado de procesos de

negocios y secuencias de transacciones

Para modelar y documentar procesos de negocios y secuencias de transacciones se

utilizan los mismos diagramas y documentos:

1) Diagrama de secuencia de transacciones (TSD)2) Descripcin textual3) Diagrama de Interaccin de Objetos (OID)4) Diagrama de Flujo de Actividad (AFD)

18.3 Diagrama de Secuencia de Transacciones (TSD)

Actores

Bor de del sistema

Secuencia de Transaccin o Proceso de Negocio

Nombre




Evento

Comunicaci%n entr e Actor y Sec.Trans.

Secuencia com'n

Descripci#n Textual: componentes

1) Abstracto:breve descripcin del proceso de negocios o secuencia de transacciones.

2) Contexto del Negocio:Especifica

- el resultado de la ST o PN. (productos/servicios)- el cliente de la ST o PN- el valor que gana el cliente con la ST o PN- el evento que inicia la ST o PN- entradas requeridas por la ST o PN- descripcin de alto nivel de la ST o PN- requerimientos especiales que controlan la ejecucin de la ST o PN

3) Camino est#ndar y al ternativo

Es una descripcin secuencial de todas las actividades que deben realizarse paraalcanzar el resultado.

No se describe el proceso de excepciones.

Para una ST describe las actividades de los actores y que debe hacer la aplicacin en

orden de servir dichas actividades.

Para un PN describe las actividades de alto nivel del proceso y qui#n las realiza.

evento

Com'n

Nombre Nombre




Los caminos alternativos se describen separadamente pero pertenecen a la misma ST o

PN. Describen casos inusuales de procesamiento y manejos de excepciones o errores.

Esta separacin se realiza para facilitar el modelado y lectura de los caminos est%ndar.

Para modelar y diagramar los caminos est%ndar y alternativos se utilizan los diagramas

de interacci#

n de objetos (OID)y los diagramas de flujo de actividad (AFD).

4) Actor es

En el BPM representan los profesionales del negocio y sistemas de computacin

involucrados en producir un producto o servicio.

En el TSM representan agentes externos que interact'an con la aplicacin. Pueden

representar usuarios humanos o interfaces con otros sistemas.

Cada actor es usado para modelar un rol. Un rol puede ser desempe+ando por un

usuario individual o grupo de usuarios.

Subdivisi#n de procesos de negocios

Los PN pueden ser subdivididos en subprocesos. Las dos formas principales pararealizar esto son:

- Especializacin: del PN en distintos tipos que producen el mismo resultado perotienen diferentes conjuntos de actividades.

- Particionamiento: del PN a lo largo del eje de tiempo en una secuencia desubprocesos.




Unidad 19: Modelado de Interaccion de Objetos

19.1 Conceptos y prop#sito del modelado de interacci#n de objetos.

Objetivo:El modelo de interaccin de objetos modela la manera en que colaboran losobjetos de un sistema para proveer la funcionalidad descrita en una secuencia de

transacciones.

Su utilidad primaria se da durante la etapa de dise+o lgico.

Interaccin de Objetos: se produce cuando un objeto env)a un mensaje a otro con el

objetivo de utilizar (requerir) la funcionalidad de la operacin invocada por el objeto

receptor del mensaje.

El modelo de interaccin de objetos provee el enlace las descripciones de las secuencias

de transacciones y las especificaciones de operaciones elementales a nivel de objetos.

Asisten en la identificacinde clases de objetos y operaciones requeridas, considerando

como una determinada funcionalidad debe distribuirse en operaciones de diferentes

clases de objetos (responsabilidadesde objetos), y como los objetos deben colaborar

para proveer la funcionalidad descrita en las secuencias de transacciones.

La herramienta de modelado fundamental para el modelado de interaccin de objetos es

el diagrama de interaccin de objetos (OID). Normalmente se usa un OID para cada

secuencia de transacciones concentr%ndose en el camino est%ndar.

Utilizaci#n del modelado de interacci#n de objetos

- Modelado de Procesos de Negocios: es una t#cnica adicional que puede utilizarsepara comprender un proceso de negocios en particular. Se considera al sistema como

una .caja negra/. Se lo representa como un actor (interface de m%quina).

- An#lisis de Requerimientos: No es muy utilizado. El propsito de esta etapa esdefinir requerimientos, no dise+ar.

- Dise%o lgico:Se utiliza un OID para cada secuencia de transacciones definida en elan%lisis de requerimientos, para determinar con claridad que clases, operaciones y

responsabilidades se necesitan. Se mira dentro de la .caja negra/(tal como se la ve

en el modelo de proceso de negocio) y se determina que objetos participan para

implementar la funcionalidad requerida del sistema.




19.2 Herramientas de modelado.

Diagrama de interacci#n de objetos para un proceso de negocios

Elementos:

1) Actores en la parte superior del diagrama. Pueden ser humanos o sistemas vistoscomo cajas negras.

2) Una l)nea vertical asociada a cada actor.3) Requerimientos o eventos enviados por un actor a otro. Se representan por flechas.

Se utilizada una sola flecha para representar el est)mulo y la respuestra impl)cita.

4) Etiquetas en el m%rgen izquierdo representando links a actividades de un diagramade flujo de actividades.

Actor 1 Actor 2 Actor 3 Sistema

1

2

Evento 1

Evento 2

Evento 3

Evento 4Evento 5

Actores

Requerimientos.

Barras: representan a losobjetos de la cabecera.

Links con actividadesde un diagrama deflujo de actividades.




Diagrama de interacci#n de objetos para una secuencia de transacciones

Elementos

1) Barra vertical a la izquierda representa el l(mite del sistema.2) Se acompa+a con la descripcin narrativa de la secuencia de transacciones a la

izquierda.

3) Una flecha proveniente desde el l)mite representa un requerimiento externogenerado por un actor. Es conveniente que los requerimientos / respuestas de este

tipo se representen por flechas individuales.

4) Operaciones: se representan por rect%ngulos alargados sobre los ejescorrespondientes a los objetos que las realizan. Permite visualizar que mensajes

dispara una operacin. La longitud de la barra no representa duracin.

5) Actividades: bloques de eventos que siempre ocurren en una determinada secuencia.Dichas actividades que pueden ocurrir en paralelo, condicional, o iterativamente,

pueden modelarse con un diagrama de flujo de actividad asociado.

Objeto 1 Ob eto 4Objeto 2 Objeto 3 Ob eto 5Objetos

Sec.Trans.

Descripnarrativa

de la S.T.1

2

3

Operaciones

Mensajes enviados por y hacia los

actores externos al sistema

L)mites del sistema




Casos Especiales

1) I nvocaci%n de Operaciones )in-self*A menudo una operacin de un objeto invoca a otra operacin de la misma clase. Esto

puede representarse de la siguiente forma:

2)M'l tiples objetos de una misma claseSe representa la clase m%s de una vez.

3)Secuencias comunesUsualmente se dibujan diagramas por separado para las secuencias comunes y su

invocacin se representa con una flecha punteada.

Diagrama de flujo de actividad.

Los OID no muestran decisiones, iteraciones, o la posibilidad de que partes del

procesamiento puedan realizarse en secuencias aleatorias o concurrentemente. Unamanera de describir esto es con descripciones textuales en el margen izquierdo del OID,

o utilizando diagramas de flujo de actividad(AFD). Los AFD son un tipo particular de

los cl%sicos flowcharts.

Actividad: es una secuencia de interacciones entre objetos




El alcance de una actividad queda normalmente definido por el hecho de que una

secuencia de interacciones dada es condicional, iterativa, o pueda ocurrir antes o

despu#s de otras secuencias de interacciones.

Simbologa de los diagr amas de f lu jo de actividad

n. Nombre

de Actividad

Actividad. El n'mero nprovee un v)nculo con

el OID asociado.

Flujo entre una actividad y la siguiente.

Divisin del flujo de actividades que pueden

ocurrir en paralelo, o en una secuencia

aleatoria.

Decisin: divisin del flujo de actividades

seg'n una condicin.

Sincronizacin.

Iteracin

Terminacin (fin).




Observaciones

- Una AFD puede incluir actividades que no est#n en un camino est%ndar pero queaparezcan en un camino alternativo.- Pueden existir actividades sin interacciones asociadas que se utilizan para clarificar

la lgica del flujo.

- Puede utilizarse un AFD sin OID asociado simplemente para describir la lgica delflujo en un camino est%ndar/alternativo.

19.3 T&cnicas avanzadas de modelado.

Generalmente, un OID es utilizado para modelar cada secuencia de transacciones. Es

posible m%s de un OID por secuencia de transacciones y se describen a continuacin dosenfoques alternativos:

Usando AFD para modelar operaciones del sistema

Los AFD pueden ser utilizados en combinacin con los OID. En un AFD cada bloque

normalmente representa un grupo de eventos que ocurren siempre en la misma

secuencia. Otra opcin es mostrar un bloque en un AFD para representar cada posible

est)mulo externo para una secuencia de transacciones. Tal est)mulo externo (u operacin

del sistema) puede ocurrir a menudo en secuencias aleatorias o en secuencias

alternativas. Un OID puede desarrollarse para cada uno de tales bloques u operaciones

del sistema.

Sin embargo se recomienda utilizar un OID simple para toda la secuencia de

transacciones siempre que sea posible, debido a que esto brinda una visin general para

todo el proceso requerido.

Diagramas de interacci#n de objetos, secuencias de transacciones y escenarios

Generalmente se desarrolla un solo OID por cada secuencia de transacciones. Este

diagrama muestra un caso general omitiendo caminos alternativos inusuales. No

muestra un escenario de ejecucin que pueda ocurrir en una ocasin espec)fica. En

casos complicados, puede ser 'til desarrollar OIDs alternativos representando los

caminos alternativos t)picos.




Unidad 20: Modelo de Ciclo de Vida de Objetos

20.1 Conceptos y prop#sito del modelo de ciclo de vida de objetos.

El modelo de ciclo de vida de objetos se utiliza para describir los aspectos din#micosdelos objetos.

El modelo de ciclo de vida de objetos modela lo que ocurre dentrode los objetos de una

clase: estados, cambios de estado, y eventos que producen dichos cambios de estado.

El estadode un objeto de una clase est%dado por el conjunto de valores de sus atributos

en un instante dado de tiempo.

Durante su ciclo de vida, desde que son creados hasta que son destruidos, los objetos

atraviesan por diferentes estados.

La importancia de estudiar el ciclo de vida de los objetos y de sus estados, se debe a que

muchos objetos exhiben comportamientos estado-dependientes.

Es especialmente importante reconocer comportamientos de objetos que son

dependientes del tiempo y del estado previo, ya que pueden agregar una complejidad

considerable a la aplicacin.

Ciertas operaciones y/o atributos pueden ser v%lidos solo en ciertos estados.

Slo deben modelarse los estados de un objeto que son relevantes al dominio de

problema que se est%modelando.

Las transicionesde estados de un objeto son causadas por la recepcin de un evento

interno o externo al sistema.

El estado que asume un objeto luego de recibir un evento depende del estado actual, del

evento recibido, y opcionalmente del valor de una condicin de guarda.Cuando un objeto recibe un evento ejecuta una accin (que corresponde con una

operacin) asociada con una transicin.

Al fin o durante la ejecucin de dicha accin, el objeto produce el cambio de estado.

Puede darse que el estado final sea el mismo que el inicial.

Utilizaci#n del modelo de ciclo de vida de objetos

Siempre que se agrega una nueva clase al OSM es importante examinar se la misma

presenta estados significantes para los objetos de la misma. Si es as)puede utilizarse el

modelo de ciclo de vida en orden de comprender correctamente el ciclo de vida de

dichos objetos.

El modelo de ciclo de vida es 'til en las etapas de an#lisis del negocio y derequerimientos para obtener una clara comprensin del ciclo de vida de los objetos

claves descubiertos y de los caminos est%ndar y alternativos involucrados.

20.2 Herramientas de modelado. Diagrama de ciclo de vida de objetos.

La herramienta que se utiliza para modelar el ciclo de vida de objetos es el diagrama de

ciclo de vida de objetos (OLD). Un OLD se aplica solo a una clase de objetos.




El OLD representa:

- como los objetos son creados- como los objetos son destruidos- como los objetos cambian a trav#s del tiempo- que estados t)picamente asume un objeto

- que eventos causan cambios de estado- que acciones realiza un objeto cuando recibe un evento que produce un cambio deestado.

Componentes del OLD

Punto de entrada: Instante previo a la creacin de un

objeto.

Punto de salida:momento en el que deja de existir un

objeto.

Estado:Conjunto de valores de los atributos de un objeto

en un instante de tiempo.

Evento [condicin de guarda]

Accin

Transici#n o cambio de estado




Ejemplo: PILA

20.3 T&cnicas avanzadas de modelado.




Unidad 21: Modelo Global del Sistema

21.1 Conceptos y prop#sito del modelo del modelo global del sistema.

El modelo global del sistema posibilita tener una visin general del modelo deestructura de objetos del sistema, asistiendo en el manejo de la complejidad.

Las principales razones para utilizar un modelo global del sistema son:

- Posibilita el particionamiento de una tarea de an%lisis o desarrollo. Para grandessistemas, subsistemas pueden ser asignados a diferentes equipos o subproyectos.

- Puede utilizarse para definir unidades de entrega, p.e., unidades funcionales(mdulos) que deban entregarse al usuario en sucesivas fechas de liberacin, o

componentes de producto.

- Puede utilizarse para definir unidades distribuibles.- Puede utilizarse para validar el dise+o de un sistema y asegurar que est% bien

dise+ado para soportar el cambio.

- Incluye un diagrama (el diagrama de visin general del sistema) que puede utilizarsepara producir una visin general de un modelo del an%lisis o de un subsistema,asistiendo con la presentacin de un modelo o subsistema a un nivel de visin

general.

Una caracter)stica importante del modelo global es que permite el modelado de

interfaces entre subsistemas. Esto se logra modelando los serviciosque un subsistema

ofrece para ser utilizados por otro subsistema.

Conceptos

El modelo global implica la subdivisin del espacio de problema en componentes. En

un enfoque de desarrollo orientado a objetos, esto se alcanza agrupando clases deobjetos. El modelado orientado a objetos difiere aqu)de las t#cnicas estructuradas, en

que en estas, los subsistemas usualmente agrupan funciones, no objetos.

Las secuencias de transacciones no necesariamente residen en un 'nico subsistema.

Pueden requerir el soporte de objetos pertenecientes a m%s de un subsistema o

componente.

El espacio del problema y sus componentes

Durante la etapa de an%lisis del negocio, el espacio del problema es el dominio del

negocio, y podemos optar por dividir dicho dominio en %reassujetos. Cada %rea sujeto

contiene clases de objetos sem%nticamente relacionadas unas a otras, vinculadas con el

mismo sujeto.

Durante el desarrollo, el espacio del problema es el sistema o subsistema que se

construye. Esto tambi#n puede ser subdividido en submodelos o subsistemas.

Los submodelos son utilizados principalmente con propsitos de presentacin.

Los subsistemas son definidos por razones t#cnicas como ser: definicin de unidades de

distribucin, y definicin de mdulos, importante para validar y preservar la

mantenibilidad del sistema.




Otro uso del particionamiento es la subdivisin arquitectural, la cual es particularmente

importante durante el dise+o f)sico. Se recomienda la divisin de todo sistema en seis

subsistemas arquitecturales:

El componente dominio de problema: es el m%s importante y en el cual nos

concentramos durante el an%lisis de requerimientos y el dise+o lgico. El componente de interfaz humana: introducido en el dise+o lgico.

El componente de interfaz externa: introducido durante el dise+o lgico.

El componente de administracin de datos: introducido durante el dise+o f)sico.

El componente de administracin de tareas: introducido durante el dise+o f)sico.

El componente de servicio de utilidades: introducido durante el dise+o f)sico.

Definici#n del alcance de un subsistema

B%sicamente, las clases de objetos que tienen un alto grado de interdependencia y sirven

a un propsito com'n, deben asignarse al mismo subsistema.

Usualmente, jerarqu)as de herencia y agregacin, deben ser asignadas completamente a

un subsistema.

Debe notarse que si existen objetos que son requeridos por diferentes subsistemas,

entonces dichos objetos no deben asignarse a un subsistema.

Servicios

Un subsistema provee sus servicios v)a una interface, la cual es un conjunto de

operaciones que los clientes de un subsistema pueden utilizar.

Es 'til estas operaciones en servicios. Cada servicio agrupa operaciones relacionadasque tienen un propsito com'n, por ejemplo, dibujar figuras, manejo de e-mail, etc.

Los servicios provistos por un subsistema a otro, o a actores, pueden identificarse

determinando que comunicaciones son posibles entre subsistemas, y agrupar estas en

servicios. Es conveniente que esto se realice durante el dise+o lgico, cuando las

operaciones han sido definidas.

Los subsistemas pueden vincularse en relaciones cliente-servidor o compa+ero-a-

compa+ero. En este 'ltimo caso, un subsistema puede ser cliente y servidor a la vez.

Particiones verticales y horizontales

Un sistema puede ser particionado horizontalmente (en capas) o verticalmente. Las

particiones verticales son usadas para subdividir la funcionalidad de la aplicacin,

mientras que las particiones horizontales son particularmente 'tiles para aislar las

aplicaciones de capas de software de menor nivel como ser sistemas operativos, bases

de datos o hardware. Este enfoque por capas (layers) asegura la portabilidad de una

aplicacin.




En el siguiente ejemplo el dominio de problema se divide en cuatro particiones

verticales. El componente de administracin de datos es una particin horizontal, la cual

existe para aislar a la aplicacin del software de base de datos utilizada.

21.2 Diagrama de Modelo Global del Sistema

Componentes del diagrama

Actor:personas que interact'an con el subsistema o interfaces con otros subsistemas.

Bordes del sistema: se representan con un rect%ngulo en l)nea gruesa. Los actores se

dibujan fuera del rect%ngulo, y los subsistemas dentro.

Subsistema:se representan con un rect%ngulo redondeado.

Servicios: se representan como semic)rculos dentro del rect%ngulo correspondiente al

subsistema.

Subsiste

ma de

Subsiste

ma de

Subsiste

ma de

Subsiste

ma de

Componente de Administracin de Datos




Actor usando un servicio: se representa como una flecha que vincula al actor con el

servicio que usa.

21.3 Conceptos avanzados

Uso de Clases de Objetos para encapsular subsistemas

Es posible encapsular la funcionalidad de un sistema utilizando object wrapper

(envoltura). Esto puede ser muy 'til para permitir la utilizacin de un sistema no

orientado a objetos desde un sistema orientado a objetos. Esto se realiza definiendo un

objeto interface el cual puede llamarse para invocar las funciones provistas por el

sistema encapsulado. Solo dicho objeto interface necesita conocer el funcionamiento

interno del sistema que encapsula.

Tambi#n es posible utilizar una clase de objetos para encapsular el acceso a un sistema

orientado a objetos. Si no se utiliza esto, todos los mensajes provenientes del exterior

del subsistema, deben dirigirse directamente a la clase de objetos correspondiente dentro

del mismo, lo que implica que los actores que necesiten utilizar la funcionalidad del

subsistema, deban conocer la estructura interna del mismo.

Utilizando un objeto interfaz, se oculta la complejidad interna del subsistema y es

posible definir una interfaz sencilla para los clientes externos.




Unidad 22: Ciclo de Desarrollo Orientado a Objetos

En los cap)tulos anteriores se introdujeron los conceptos fundamentales del paradigma

de orientacin a objetos, como as)tambi#n los modelos fundamentales que se utilizar%nen la presente metodolog)a de OOAD.

En los prximos cap)tulos se examinar%el procesode desarrollo orientado a objetos, es

decir que actividades deben llevarse a cabo, que tareas deben realizarse, y que

entregables deben producirse en cada etapa.

En esta unidad se realiza una presentacin a nivel general que se desarrolla en detalle en

las unidades siguientes.

22.1 Fases del ciclo de desarrollo O.O.

Este enfoque un ciclo de vida tradicional compuesto por las siguientes etapas:

Definicin del proyecto y planificacin:aqu)es donde se define el alcance y l)mitesdel proyecto. Se realizan los estudios de factibilidad y relaciones costo/beneficio.

An#lisis

- An#lisis del Negocio:aqu)es donde se modela el negocio o parte del mismo enorden de comprender la naturaleza del mismo, como se realizan actualmente las

actividades, y como los usuarios desean que se realicen en el futuro. Provee una

comprensin preliminar de %reas espec)ficas del negocio a ser informatizadas.

Esta etapa tambi#n es conocida como estudio del sistema actual en otras

metolog)as.

- An#lisis de requerimientos del sistema:aqu)es donde se establece con claridadlas capacidades requeridas para el nuevo sistema a ser desarrollado. Estas

capacidades son documentadas de modo tal que los desarrolladores tengan una

especificacin clara sobre la que trabajar y para validar los resultados obtenidos.

Dise%o

- Dise%o Lgico: aqu) es donde los desarrolladores del sistema identifican loscomponentes de software/hardware necesarios para satisfacer los

requerimientos, como as)tambi#n especifican las relaciones arquitecturales entre

dichos componentes. El dise+o lgico debe evitar detalles t#cnicos espec)ficos

requeridos para mapear el dise+o en un entorno de implementacin espec)fico.

- Dise%o F(sico: aqu) es donde se toman decisiones t#cnicas considerandoarquitecturas de hardware espec)ficas, sistemas de bases de datos, lenguajes de

programacin, utilizacin de paquetes de middleware o paquetes GUI, etc. Aqu)

tambi#n se toman decisiones con respecto a caracter)sticas de implementacin

como ser arquitectura cliente/servidor, distribucin de objetos, etc.

Construccin




- Desarrollo:aqu)es donde un dise+o f)sico es implementado en un lenguaje deprogramacin, o entorno espec)fico de desarrollo.

- Prueba:se realizan testes del software para validar su correcto funcionamiento y

detectar fallas que deban ser depuradas.

- Documentacin: desarrollo de documentacin t#cnica sobre la aplicacin,manuales de usuario, manuales de procedimiento, etc.

Aprobacin

Operacin y Mantenimiento

22.2 Uso de los distintos modelos.A continuacin se sumariza el uso de los distintos modelos en las diferentes etapas del

ciclo de desarrollo:

An(lisis del Negocio

Modelo de Estructura de Objetos:es utilizado para identificar y modelar los objetosdel dominio del negocio (objetos entidad). Preguntas fundamentales son: .Qu#

objetos necesitamos en orden de realizar los procesos de negocio identificados?/,

.Qu#deben conocer estos objetos, y que deben ser capaces de realizar?/, .Cmo

interact'an estos objetos entre si?/.

Modelo de procesos de negocios y secuencias de transacciones:pueden utilizarsepara describir los procesos del negocio en una forma compatible con la descripcin

de secuencias de transacciones de la siguiente fase de an%lisis de requerimientos.

Modelo de Ciclo de Vida de Objetos:pueden proveer una mayor comprensin sobreel comportamiento din%mico de los objetos del negocio, durante su vida. Su

utilizacin depender%de la complejidad de los objetos del negocio en estudio, y en

algunos casos puede ser innecesaria su utilizacin.

An(lisis de Requerimientos Modelo de estructura de Objetos:contiene 'nicamente objetos entidad, y se agrega

mayor detalle al modelo describiendo relaciones, herencia, agregacin, atributos y

restricciones aplicables a las clases de objeto entidad identificados.

Secuencias de Transaccin:son utilizadas para describir la funcionalidad esperadadel sistema.




Modelo de Ciclo de Vida de Objetos:se utiliza para aquellos objetos con ciclos devida complejos.

Modelo Global del Sistema:es utilizado para sistemas grandes cuando se necesiteparticionar en subsistemas.

Diseo L#gico

Secuencias de Transacciones:definidas en la etapa anterior, son examinadas aqu)para determinar objetos interfaz y de control donde es apropiado.

Diagramas de Interaccin de Objetos: se dibuja uno por cada secuencia detransaccin describiendo eventos e interacciones entre objetos necesarios para

soportar la secuencia de transaccin.

Operaciones:son definidas con descripciones informales de su comportamiento.

Diagramas de Ciclo de Vida:son creados y extendidos donde sean necesarios.

Modelo Global:se definen subsistemas y se dibujan diagramas globales donde searequerido con propsitos organizacionales, manejo de complejidad, y presentacin.

Diseo F*sico

Durante la etapa de dise+o f)sico se llevan a cabo las siguientes actividades:

El entorno para el sistema debe ser determinado, y las decisiones tomadasinicialmente deben finalizarse. Esto incluye determinacin de lenguaje de

programacin, sistema operativo, Dbms, s.o. de red, hardware, tipo de interface de

usuario, librer)as de clases, frameworks, y patrones de dise+o.

La administracin de tareas y distribucin de objetos/funciones debe finalizarse.

La definicin de tipos de atributos debe finalizarse.

Se implementan las relaciones (p.e. en forma de punteros)

Decisiones relativas a implementacin de restricciones debe finalizar, dependiendodel lenguaje de programacin, GUI-builder, y/o Dbms utilizados.

Debe finalizarse la interface de usuario.

Deben tomarse decisiones sobre el manejo de persistencia de objetos, involucrandoposiblemente un mapeo entre objetos y Dbms relacionales. Esto puede implicar la

implementacin de una .capa de acceso/en el sistema, o bien puede manejarse con

un producto comercial.

Se desarrollan objects wrappers para todos los componentes no orientados a objetosque ser%n utilizados por la aplicacin.




Se realiza la codificacin de todas las operaciones que deban realizarse.

El rol de las versiones en un proceso de desarrollo aditivo

El proceso de OOAD descripto aqu)es aditivo, esto significa que los resultados de cadafase son utilizados como entrada para la siguiente fase, donde se realizan

actualizaciones y extensiones. Esto contrasta con otros enfoques como el estructurado

que es car%cter transformacional, donde los DFD del an%lisis son transformados en

Diagramas de Estructura durante el dise+o.

Debido a esta naturaleza aditiva del proceso, es t#cnicamente innecesario retener

versiones de resultados de las primeras fases del desarrollo. Sin embargo muchas veces

por cuestiones contractuales u organizacionales se retienen copias de los modelos del

an%lisis de requerimientos. A menudo, este modelo representa un contrato entre los

usuarios y los desarrolladores. El modelo se retiene en orden de proveer un mecanismo

para validar que el sistema entregado cumple con las especificaciones iniciales.

22.3 Arquitectura de Seis Componentes

Como se ha mencionado, es 'til y com'n dividir sistemas grandes y complejos en

subsistemas para facilitar su desarrollo. Pero adem%s es 'til dividir un sistema de

cualquier tama+o en subsistemas basados en consideraciones arquitecturales que son

espec)ficamente relevantes durante la fase de dise+o f)sico de la aplicacin.

El presente enfoque de desarrollo orientado a objetos recomienda la siguiente

arquitectura de seis componentes:

Componente Dominio de Problema (PDC)

Componente de Interaccin Humana (HIC)

Componente de Interfaces Externas (EIC)

Componente de Administracin de Datos (DMC)

Componente de Administracin de Tareas (TMC)

Componente de Servicio de Utilidades (USC)

PDC

HIC

PDC

PDC

HIC

EIC

EIC

USC DMC

TMC

An%lisis

(del Negocio y Requerimientos)

Dise+o Lgico

Dise+o F)sico

Clases de Objetos




En la unidad de Dise+o F)sico se discuten en detalle cada uno de estos componentes.

Unidad 23: An(lisis del NegocioEl an#lisis del negocioes utilizado para modelar parte o toda la empresa, en orden de

comprender la naturaleza del negocio y como se llevan a cabo sus procesos.

El an%lisis del negocio se concentra en dos aspectos:

Modelado de lo Objetos que soportan el negocio (business objects)

Modelado de los Procesos del Negocio (business processes)

23.1 Actividades del An(lisis del Negocio

Las siguientes actividades son llevadas a cabo durante el an%lisis del negocio:

Identificacin de los Objetos del Negocio. Son los objetos m%s importante del tipoentidad. Otros objetos entidad adicionales son agregados durante el an%lisis de

requerimientos y durante el dise+o lgico.

Modelado del ciclo de vida para cada objeto del negocio que tenga un ciclo de vidacomplejo relevante al problema a manejar.

Modelado de los procesos de negocio. Implica la identificacin de los procesos denegocio y la obtencin de una comprensin de alto nivel de los flujos de trabajo

(workflows: secuencias de actividades y eventos) de dichos procesos, y de los

agentes (humanos o m%quinas) que interact'an para alcanzar un resultado

significativo.

Chequeo de consistencia y validacin del modelo producido.

El alcance del an%lisis del negocio (dominio del negocio o dominio del problema)

normalmente se determina durante la fase de definicin del proyecto.

23.2 Modelado de Objetos del Negocio

El modelado de objetos del negocio es la primera definicin del modelo de estructura de

objetos para la aplicacin.

El modelado de objetos puede realizarse en simult%neo con el modelado de procesos de

negocios. Sin embargo se recomienda comenzar modelando los objetos ya que son laesencia de este enfoque.

El modelo de estructura de objetos producido en esta fase ser% extendido en fases

subsiguientes. Sin embargo es muy similar al de la fase de an%lisis de requerimientos.

Las principales diferencias residen en:

El alcance de los objetos del negocio suele ser mayor, pues puede involucrar objetosde negocio que no son relevante al sistema computarizado.




El modelo de objetos del negocio suele ser menos detallado. Usualmente soloobjetos del la realidad son modelados. Durante el an%lisis de requerimientos, objetos

menos obvios (p.e. clases que representan eventos) son identificados.

En el an%lisis del negocio, el modelo contiene los objetos del negocio, susprincipales atributos y relaciones est%ticas relevantes. Durante el an%lisis de

requerimientos, pueden agregarse objetos entidad adicionales, con un conjunto deatributos m%s detallado y las operaciones b%sicas para los objetos del modelo.

La definicin de jerarqu)as de herencia y estructuras de agregacin se difieren hastael an%lisis de requerimientos.

Pasos en el modelado de objetos de negocio

El modelado de objetos de negocio incluye los siguientes pasos:

1. Determinar objetos del negocio candidatos2. Abstraer los objetos candidatos en clases y definir el propsito de cada clase de

objetos.

3. Determinar las relaciones est%ticas entre los objetos del negocio.

4. Nominar dichas relaciones y asignar cardinalidades.

Qu&modelar?

Los objetos pueden ser identificados respondiendo la pregunta: .Qu# cosas (reales o

abstractas) considera la empresa y sobre la que guarda datos?/.

El #nfasis en esta etapa es identificar objetos de la realidad (personas, lugares, cosas o

eventos) que est%n dentro del dominio del negocio.

23.3 Modelado de Ciclo de Vida de ObjetosEl principal propsito del modelado de ciclo de vida de objetos es asistir en lacomprensin de objetos con ciclos de vida complejos.

Es importante reconocer cualquier comportamiento del objeto que sea dependiente del

tiempo y del estado del mismo, ya que esto agrega complejidad a la aplicacin.

El uso de diagramas de ciclo de vida facilita la comprensin y comunicacin con

usuarios.

Cuando modelar ciclos de vida?

Debe dibujarse diagramas de ciclos de vida solo para objetos que poseencomportamientos dependientes del tiempo y de su estado interno. Para determinar esto,

debe tomarse cada clase de objetos y analizarla por separado. Deben identificarse loseventos que pueden afectar a un objeto de la clase y determinar si la reaccin a dichos

eventos puede variar seg'n el estado interno del objeto.

Como modelar ciclos de vida de objetos

El modelado de ciclos de vida incluye los siguientes pasos:

1. Determinar cuando debe modelarse el ciclo de vida para una clase de objetos, seg 'nlo expuesto en el punto anterior.

2. Identificar el primer estado del objeto.




3. Identificar que evento lleva a un objeto a su estado inicial (usualmente la creacindel mismo).

4. Identificar los eventos que pueden causar transiciones de estado desde el primerestado, y a que otros estados puede cambiar el objeto. Identificar que actividades se

llevan a cabo durante la transicin de estado.

5. Identificar el estado final del objeto.

B%sicamente el alcance del modelado de ciclo de vida de objetos es el mismo para la

actividad de an%lisis del negocio como para el an%lisis de requerimientos.

23.4 Modelado de Procesos de Negocio.

El modelado de procesos de negocio es usado para comprender y documentar las

actividades de alto nivel realizadas por los profesionales del negocio para alcanzar los

objetivos del dominio del negocio.

Esta comprensin de alto nivel de cmo trabaja la empresa es necesaria como un pasopreliminar para asegurar que las parte del negocio afectada por la aplicacin en

desarrollo es comprendida antes de que el an%lisis de requerimientos sea llevada a cabo.

Pasos del modelado de procesos de negocio

1. Identificar los procesos de negocio.2. Subdivisin de los procesos de negocio. Los procesos de negocio pueden

subdividirse identificando especializaciones o particion%ndolos a lo largo del tiempo

en subprocesos.

3. Descripcin de los procesos de negocio. La descripcin de un proceso de negocioimplica la descripcin de la naturaleza del mismo como de las actividades que lo

constituyen.

Identificaci#n de procesos de negocio

Los procesos de negocio pueden identificarse de dos maneras:

1. Considerar Qui#n es el Cliente, y Qu#productos o servicios requiere. Verificar quedichos productos/servicios sean de valor para el cliente. La produccin de dichos

productos/servicios implicar%n uno o m%s procesos de negocio.

2. Considerar que eventos la empresa debe ser capaz de tratar, y que procesos implicanel tratamiento de dichos eventos.

Como describir procesos de negocio

Los siguientes mecanismos pueden utilizarse para describir procesos de negocio:

1. Una identificacin del evento inicial y del producto(s) o servicio(s) del proceso denegocios.

2. Una descripcin textualde las actividades involucradas en el proceso de negocio.3. Una descripcin de la secuencia de interacciones entre agentes (humanos o

m%quinas) que es requerida para producir el producto/servicio requerido. Para esta

descripcin pueden utilizarse diagramas de interaccin de objetos.

4. Una descripcin de los caminos de ejecucin involucrados en el proceso, mostrandolos puntos en los cuales se inician dichos caminos: alternativos, actividades

paralelas, e iteraciones. Para esto se pueden utilizar diagramas de flujo de actividad.




23.5 Chequeo del modelo de an(lisis del negocio.




Unidad 24: An(lisis de RequerimientosEl proceso de an%lisis de requerimientos debe producir una definicin clara de los

requerimientos para el nuevo sistema desde la cual puedan trabajar los desarrollado

Documents

Analisis y Diseño Orientado a Objetos