SI - Metodolgica Orientado a Objetos

Alumnos: Marco Gamarra Oblitas Garca Moreano, Alejandro Francisco Max Gutirrez Bravo

CONCEPTO ORIENTADO A OBJETOS La programacin orientada a objetos difiere de la programacin tradicional. Cada objeto es una representacin de alguna cosa o evento real.

Beneficios de la Metodologa Orientada a Objetos.

Promueve la reusabilidad. Reduce la complejidad del mantenimiento (extensibilidad y facilidad de cambios). Riqueza semntica. Disminuye la brecha semntica entre la visin interna y la visin externa del sistema. Facilita la construccin de prototipos.

Objetos personas, lugares o cosas relevantes para el sistema a analizar. Los sistemas orientados a objetos describen las entidades como objetos.
Este auto es un objeto

Clases Los objetos se representan y agrupan mediante clases. define el conjunto de atributos compartidos y comportamientos que se encuentran en cada objeto de la clase. Los nombres son sustantivos o frases cortas y empiezan con mayscula. Se representan mediante rectngulos. contienen dos caractersticas importantes: una lista de atributos (describe una propiedad que posee el objeto) y una serie de mtodos (accin que puede efectuar cualquier objeto ).
AutoVenta ao de fabricacin color marca tipo

Nombre de la clase
Atributos

vender() probar()

mtodos

Herencia se puede crear una clase a partir de otra. En UML, si hay una clase padre y una clase hija , la hija adems de poder tener todos los atributos y mtodos de la clase padre puede tener otros adicionales. En un diagrama de clases los atributos llevan un signo negativo porqu son privados ,mientras que los mtodos un signo positivo por ser pblicos (otras clases pueden invocarlos). La herencia es una herramienta que se encuentra solo en los sistemas orientados a objetos.
Medios de transporte Auto -velocidad -medio -tamao -marca +transportar()

-velocidad -medio -tamao

+transportar()

Barco -velocidad -medio -tamao +transportar() +navegar()

Conceptos del UML

El UML consiste en cosas, relaciones y diagramas. UML provee un conjunto de herramientas para documentar el anlisis y diseo de un sistema de software. Entre las herramientas se incluye diagramas que permiten visualizar la construccin de un sistema orientado a objetos. La documentacin provee un medio efectivo de comunicacin entre el equipo de desarrollo y el equipo de negocios en un proyecto.

Cosas o Objetos permiten al usuario a describir las relaciones. Las cosas de comportamiento describen el funcionamiento de las cosas. Las cosas de grupos se usan para definir limites. Las cosas de anotaciones se usan para agregar notas a los diagramas. Relaciones Las relaciones mantienen las cosas unidades entre s. Las relaciones estructurales se usan para unir las cosas en los diagramas estructurales; incluyen dependencias, agregaciones, asociaciones y generalizaciones; muestran herencia. Las relaciones de comportamiento se usan en los diagramas de comportamiento, los tipos bsicos de este tipo de relacin son: comunica, incluye, extiende y generaliza.

Diagramas del UML Diagramas estructurales se usan para describir relaciones entre las clases, dividindose en diagrama de clases, diagramas de objetos, diagramas de componentes y diagramas de despliegue. Los diagramas de comportamiento se usan para describir la interaccin entre los actores y los casos de uso, o la forma en que los actores usan el sistema , se dividen en diagramas de casos de uso, diagramas de secuencia, diagramas de comunicacin, diagramas de estados, y diagramas de actividad. Los seis diagramas UML que se utilizan con ms frecuencia son: 1. Un diagrama de casos de uso (uso del sistema) 2. Un escenario de caso de uso (aunque tcnicamente no es un diagrama) 3. Un diagrama de Actividad (ilustra el flujo de actividades )* 4. Los diagramas de secuencia ( muestran la secuencia de actividades y las relaciones ) * 5. Los diagramas de clases (muestran las clases y sus relaciones). 6. Los diagramas de estados (muestran las transiciones de estado).

EJEMPLO: Al comenzar cada semestre, los estudiantes requieren un catlogo que contiene la lista delos cursos ofrecidos para cada semestre. La informacin de cada curso, como el profesor, facultad y pre-requisitos sern incluidos para ayudar a los estudiantes en la toma de decisiones. El nuevo sistema les permitir a los estudiantes seleccionar cuatro cursos para el semestre entrante. Adems, cada estudiante indicar dos alternativas en caso de que un curso ofrecido se llene o sea cancelado. Ningn curso ofrecido tendr ms de 10estudiantes, ni menos de 3 estudiantes. Un curso con menos de 3 estudiantes ser cancelado. Una vez el proceso de matrcula es completado por el estudiante, el sistema de matrcula enva la informacin al sistema financiero. Los profesores deben acceder el sistema en lnea para indicar cul curso ensear. Tambin necesitan conocer cules estudiantes estn matriculados para su curso. Para cada semestre, existe un periodo de tiempo en el cual el estudiante puede cambiar su horario. Los estudiantes accedern el sistema durante este tiempo y aadir y cancelar cursos.

1. Defina el modelo de casos de uso. Qu es un caso de uso? o Describe qu hace un sistema pero no especifica cmo lo hace o debe ser simple, claro y conciso Cmo se Presentan? o Un caso de uso se representa en UML como ovalo:

Actores Representa un rol que es jugado por una persona, un dispositivo hardware u otro sistema que interacte con nuestro sistema Se puede definir categoras generales de actores (como cliente) y especializarlos (como Cliente Comercial) a travs de relaciones de generalizacin

SOLUCION: Actores Estudiantes Profesores Sistema Financiero Administrador Sistema

Casos de Uso Estudiantes Matricular Profesores Seleccionar cursos a ensear Requerir lista del curso Administrador Sistema Mantener informacin del curso Mantener informacin del estudiante Mantener informacin profesor Generar catlogo

Relaciones de los Casos de Uso

En los casos de uso pueden participar cuatro tipos de relaciones: asociacin, generalizacin, inclusin y extensin. Cada relacin tiene su propsito y notacin. Relacin Propsito Notacin Asociacin Denota una relacin entre un actor y un caso de uso. Generalizacin Denota herencia entre casos de uso Inclusin Incluye la funcionabilidad de un caso de uso en otro Extiende la funcionabilidad de un caso de uso a otro bajo ciertas circunstancias <<Include>

Extensin

<<extend >

2. Diagramas de Actividad. a) Despus de crear el caso de uso se pueden realizar los diagramas de actividades para presentar grficamente las actividades o flujos de eventos dentro de los casos de uso. El diagrama de actividades puede extender la discriminacin de los casos de uso. Son similares a los diagramas de flujo que describe el orden de las actividades de un proceso. Se de realizar un diagrama actividades por cada caso de uso. b) Contiene los siguientes elementos: Bifurcacion
Actividad

Flujo Inicio

union

Fin Subdivision

Una flecha representa un evento. Los eventos representan cosa que ocurren en cierto momento. Un diamante representa una decisin ( tambin conocida como ramificacin) o una fusin.

Unin

DIAGRAMA DE ACTIVIDAD CASO USO DE MATRICULA

3. DIAGRAMA SECUENCIAL 1.Diagrama que representa una interaccin centrndose en: a.La secuencia de mensajes que se intercambian b.Sus correspondientes ocurrencias de eventos sobre lneas de vida. 2.Muestra las interacciones entre objetos ordenadas en secuencia temporal. 3.Incluye secuencias temporales pero no incluye relacin entre objetos. 4.En aplicaciones grandes adems de los objetos se muestran: a.Los componentes: Objetos reutilizamos. b.Los CU: Objetos cuyo rol es implementar el CU. 5.Documentar el diseo desde el punto de vista del CU. Consideraciones adicionales Actor: Instancia de un actor en RunTime. Clases Entidad: Moldean el mundo real Clases Interfaz: Son puente entre el sistema y el usuario Clases Control: Implementan la lgica del negocio que no puede ser fcilmente implementada en una clase entidad o interfaz.

4. Desarrollo de Diagramas de clases Diagramas que muestra una coleccin de elementos declarativos ( estticos) de un modelo, como clases y tipos, junto con sus contenidos relacionales. Son la espina dorsal del UML. Elementos que forman un diagrama de clases: o Clases o Relaciones

Diagramas de Clase (PERSPECTIVAS)

Conceptual

o Permite representar los conceptos del dominio

Especificacin:

o Cuando se trata de representar las interfaces del sw y no el sw en si. Implementacin o Es en esta perspectiva donde realmente tenemos clases, siendo esta la perspectiva mas utilizada.

Clases de UML o Tienen un nombre que las distingue de las otras clases o No hay porque presentar toda su informacin o VISIBILIDAD public + : cualquier clase externa con visibilidad hacia la clase dad puede utilizar un atributo u operacin de esta clase. protected # : Cualquier descendiente de la clase. Prvate - : Solo la propia clase puede utilizar la caracterstica. Relacin de Clases o Relacin de asociacin de multiplicidad Numero de objetos (1.n) o Relacin de agregacin R. Composicin: Una clase esta compuesta por otras R. Agregacin: Una clase tiene otra clase de otras

1. DIBUJE EL DIAGRAMA DE ESTADOS Los diagramas de transicin de estados son similares a los diagramas de actividad. muestra como cambia un objeto a travs del tiempo. Todos los objetos tienen un estado(estado en el que existe) y un valor lo determina el valor de sus atributos. El estado inicial es el que posee un objeto cuando es creado y es obligatorio. El estado final que indica el final de la vida del objeto y es opcional. Un evento es una ocurrencia que sucede en un punto del tiempo, es determinado por los estados Una transicin es un cambio hecho de un estado original a un estado sucesor. Una accin es una operacin que est asociada con una transicin. a. Diagrama de estados objeto curso

RUP Rational Unified Process

Es un proceso de desarrollo de software y junto con el UML, constituye la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos. Sus metodologas son adaptables al contexto y necesidades de cada organizacin, donde el software es organizado como una coleccin de unidades atmicas llamados objetos, constituidos por datos y funciones, que interactan entre s. Est incluido en el Rational Method Composer (RMC), que permite la personalizacin de acuerdo a necesidades.

RUP se divide en 4 fases, dentro de las cuales se realizan varias iteraciones segn el proyecto y en las que se hace mayor o menos esfuerzo en las distintas actividades. En las iteraciones de cada fase se hacen diferentes esfuerzos en diferentes actividades: Fase de Inicio (Inspeccin y Concepcin): Se hace un plan de fases, donde se identifican los principales casos de uso y los riesgos. Se concreta la idea, la visin del producto, como se enmarca en el negocio, el alcance del proyecto Fase de Elaboracin: se realiza el plan de proyecto, donde se completan los casos de uso y se mitigan los riesgos. Planificar las actividades necesarias y los recursos requeridos, especificando las caractersticas y el diseo de la arquitectura. Fase de Construccin: elaboracin de un producto totalmente operativo y en la elaboracin del manual de usuario. Construir el producto, la arquitectura y los planes, hasta que el producto est listo para ser enviado a la comunidad de usuarios. Fase de Transicin: realiza la instalacin del producto en el cliente y se procede al entrenamiento de los usuarios. Realizar la transicin del producto a los usuarios, lo cual incluye: manufactura, envo, entrenamiento, soporte y mantenimiento del producto, hasta que el cliente quede satisfecho, por tanto en esta fase suelen ocurrir cambios.

interacciones entre las etapas de RUP.

gracias