UML José Vargas Mery.

UML José Vargas Mery

Diagramas UML UML ofrece cinco grupos diferentes de diagramas para modelar un sistema Casos de Uso Estructura Estado Comportamiento Implementación Teaching Notes UML offers five different groups (use case, structure, state, behavior, & implementation) of diagrams to model a system much like a set of blueprints used for constructing a house. Use case diagrams (use case) graphically depict the interactions between the system and external systems and users. In other words they graphically describe who will use the system and in what ways the user expects to interact with the system. The use case narrative is used in addition to textually describe the sequence of steps of each interaction. Class diagrams (structure) depict the system’s object structure. They show object classes that the system is composed of as well as the relationships between those object classes. Object diagrams (structure) are similar to class diagrams, but instead of depicting object classes, it models actual object instances—showing the current values of the instance’s attributes. The object diagram provides the developer with a “snapshot” of the system’s objects at one point in time. This diagram is not used as often as a class diagram, but when used, can help a developer better understand the structure of the system. Sequence diagrams (behavior) graphically depict how objects interact with each other via messages in the execution of a use case or operation. They illustrate how messages are sent and received between objects and in what sequence. Collaboration diagrams are similar to sequence diagrams but do not focus on the timing or “sequence” of messages. Instead, they present the interaction (or collaboration) between objects in a network format. State diagrams (state) are used to model the dynamic behavior of a particular object. They illustrate an object’s life cycle—the various states that an object can assume and the events that cause the object to transition from one state to another. Activity diagrams (state) are used to graphically depict the sequential flow of activities of either a business process or a use case. They also can be used to model actions that will be performed when an operation is executing as well as the results of those actions. Component diagrams (implementation) are used to graphically depict the physical architecture of the system. They can be used to show how programming code is divided into modules (or components). Deployment diagrams (implementation) describe the physical architecture of the hardware and software in the system. They depict the software components, processors, and devices that make up the system’s architecture.

Diagramas UML Diagramas de Casos de Uso Diagramas de Clases de Objetos
Diagramas de Colaboración Diagramas de Secuencia Diagramas de Estados Diagramas de Actividades Diagramas de Despliegue Diagramas de Componentes Modelo del Sistema Teaching Notes UML offers five different groups (use case, structure, state, behavior, & implementation) of diagrams to model a system much like a set of blueprints used for constructing a house. Use case diagrams (use case) graphically depict the interactions between the system and external systems and users. In other words they graphically describe who will use the system and in what ways the user expects to interact with the system. The use case narrative is used in addition to textually describe the sequence of steps of each interaction. Class diagrams (structure) depict the system’s object structure. They show object classes that the system is composed of as well as the relationships between those object classes. Object diagrams (structure) are similar to class diagrams, but instead of depicting object classes, it models actual object instances—showing the current values of the instance’s attributes. The object diagram provides the developer with a “snapshot” of the system’s objects at one point in time. This diagram is not used as often as a class diagram, but when used, can help a developer better understand the structure of the system. Sequence diagrams (behavior) graphically depict how objects interact with each other via messages in the execution of a use case or operation. They illustrate how messages are sent and received between objects and in what sequence. Collaboration diagrams are similar to sequence diagrams but do not focus on the timing or “sequence” of messages. Instead, they present the interaction (or collaboration) between objects in a network format. State diagrams (state) are used to model the dynamic behavior of a particular object. They illustrate an object’s life cycle—the various states that an object can assume and the events that cause the object to transition from one state to another. Activity diagrams (state) are used to graphically depict the sequential flow of activities of either a business process or a use case. They also can be used to model actions that will be performed when an operation is executing as well as the results of those actions. Component diagrams (implementation) are used to graphically depict the physical architecture of the system. They can be used to show how programming code is divided into modules (or components). Deployment diagrams (implementation) describe the physical architecture of the hardware and software in the system. They depict the software components, processors, and devices that make up the system’s architecture.

Diagramas UML Casos de Uso Diagramas de Casos de Uso Estructura
Diagramas de Clases Diagramas de Objetos Estado Diagramas de Estados Diagramas de Actividades Comportamiento Diagramas de Secuencia Diagramas de Colaboración Implementación Diagramas de Componentes Diagramas de Despliegue Teaching Notes UML offers five different groups (use case, structure, state, behavior, & implementation) of diagrams to model a system much like a set of blueprints used for constructing a house. Use case diagrams (use case) graphically depict the interactions between the system and external systems and users. In other words they graphically describe who will use the system and in what ways the user expects to interact with the system. The use case narrative is used in addition to textually describe the sequence of steps of each interaction. Class diagrams (structure) depict the system’s object structure. They show object classes that the system is composed of as well as the relationships between those object classes. Object diagrams (structure) are similar to class diagrams, but instead of depicting object classes, it models actual object instances—showing the current values of the instance’s attributes. The object diagram provides the developer with a “snapshot” of the system’s objects at one point in time. This diagram is not used as often as a class diagram, but when used, can help a developer better understand the structure of the system. Sequence diagrams (behavior) graphically depict how objects interact with each other via messages in the execution of a use case or operation. They illustrate how messages are sent and received between objects and in what sequence. Collaboration diagrams are similar to sequence diagrams but do not focus on the timing or “sequence” of messages. Instead, they present the interaction (or collaboration) between objects in a network format. State diagrams (state) are used to model the dynamic behavior of a particular object. They illustrate an object’s life cycle—the various states that an object can assume and the events that cause the object to transition from one state to another. Activity diagrams (state) are used to graphically depict the sequential flow of activities of either a business process or a use case. They also can be used to model actions that will be performed when an operation is executing as well as the results of those actions. Component diagrams (implementation) are used to graphically depict the physical architecture of the system. They can be used to show how programming code is divided into modules (or components). Deployment diagrams (implementation) describe the physical architecture of the hardware and software in the system. They depict the software components, processors, and devices that make up the system’s architecture.

Actividades Generales del análisis Orientado Objeto
Modelar las funciones del sistema. Encontrar e identificar los objetos del negocio. Organizar los objetos e identificar sus relaciones. Modelar el comportamiento de los objetos. No additional notes.

Modelación de Casos de Uso
Modelación de las funciones de un sistema en términos de los eventos del negocio, quién los inicia, y cómo responde el sistema a ellos. Teaching Notes Use cases describe the system functions from the perspective of external users and in the manner and terminology in which they understand. To accurately and thoroughly accomplish this demands a high level of user involvement. Use cases are the results of decomposing the scope of system functionality into many smaller statements of system functionality. The creation of use cases has proven to be an excellent technique in order to better understand and document system requirements. A use case itself is not considered a functional requirement, but the story (scenario) the use case tells captures the essence of one or more requirements. Use cases are initiated or triggered by external users or systems called actors. An actor initiates system activity, a use case, for the purpose of completing some business task. An actor represents a role fulfilled by a user interacting with the system and is not meant to portray a single individual or job title.

Caso de Uso Secuencia de pasos o actividades relacionadas por su comportamiento (un escenario), tanto automatizadas como manuales, que tienen como fin completar una única tarea del negocio. Notación en UML Teaching Notes Use cases describe the system functions from the perspective of external users and in the manner and terminology in which they understand. To accurately and thoroughly accomplish this demands a high level of user involvement. Use cases are the results of decomposing the scope of system functionality into many smaller statements of system functionality. The creation of use cases has proven to be an excellent technique in order to better understand and document system requirements. A use case itself is not considered a functional requirement, but the story (scenario) the use case tells captures the essence of one or more requirements. Use cases are initiated or triggered by external users or systems called actors. An actor initiates system activity, a use case, for the purpose of completing some business task. An actor represents a role fulfilled by a user interacting with the system and is not meant to portray a single individual or job title.

Actor Representa cualquier cosa que necesita interactuar con el sistema para intercambiar información. Un actor es un usuario del sistema, un rol, que puede ser tanto una persona como un sistema externo. En un caso de uso, hay un actor que inicia la acción y, posiblemente, otros actores participantes. Notación en UML Cajero Teaching Notes Use cases describe the system functions from the perspective of external users and in the manner and terminology in which they understand. To accurately and thoroughly accomplish this demands a high level of user involvement. Use cases are the results of decomposing the scope of system functionality into many smaller statements of system functionality. The creation of use cases has proven to be an excellent technique in order to better understand and document system requirements. A use case itself is not considered a functional requirement, but the story (scenario) the use case tells captures the essence of one or more requirements. Use cases are initiated or triggered by external users or systems called actors. An actor initiates system activity, a use case, for the purpose of completing some business task. An actor represents a role fulfilled by a user interacting with the system and is not meant to portray a single individual or job title.

Casos de Uso - ejemplo El siguiente caso de uso de alto nivel describe el proceso de comprar artículos en una tienda cuando se emplea una terminal en el punto de venta. Caso de uso: Comprar productos Actores: Cliente, Cajero Tipo: Primario Descripción: Un Cliente llega a la caja registradora con los artículos que comprará. El Cajero registra los artículos y cobra el importe. Al terminar la operación, el Cliente se marcha con los artículos comprados. Teaching Notes Use cases describe the system functions from the perspective of external users and in the manner and terminology in which they understand. To accurately and thoroughly accomplish this demands a high level of user involvement. Use cases are the results of decomposing the scope of system functionality into many smaller statements of system functionality. The creation of use cases has proven to be an excellent technique in order to better understand and document system requirements. A use case itself is not considered a functional requirement, but the story (scenario) the use case tells captures the essence of one or more requirements. Use cases are initiated or triggered by external users or systems called actors. An actor initiates system activity, a use case, for the purpose of completing some business task. An actor represents a role fulfilled by a user interacting with the system and is not meant to portray a single individual or job title.

Cursos de Eventos Curso normal de los eventos
Describe en detalles la interacción entre los actores y el sistema. Un aspecto esencial es que explica la secuencia más común de los eventos; no incluye situaciones alternativas. Curso alternativo de los eventos Describe importantes opciones o excepciones que pueden presentarse en relación con el curso normal. Si son complejas, se pueden expandir y convertir en otros casos de uso.

Curso Normal de Eventos
Acción de los actores Respuesta del sistema 1. Este caso de uso comienza cuando un Cliente llega a una caja TPDV (Terminal de Punto de Ventas) con productos que desea comprar. 2. El Cajero registra la identificación de cada producto. Si hay varios productos de una misma categoría, el Cajero también puede introducir la cantidad. 3. Determina el precio del producto e incorpora a la transacción actual la información correspondiente. Se presentan la descripción y el precio del producto actual. 4. Al terminar de introducir los productos, el Cajero indica al TPDV que se concluyó la captura de productos. 5. Calcula y presenta el total de la venta. 6. El Cajero indica el total al Cliente.

Curso Normal de Eventos
7. El Cliente efectúa el pago en efectivo – el “efectivo ofrecido” – posiblemente mayor que el total de la venta. 8. El Cajero registra la cantidad de efectivo recibida. 9. Muestra al cliente la diferencia. Genera un recibo. 10. El Cajero deposita el efectivo recibido y extrae el cambio de pago. El Cajero le da al Cliente el cambio y el recibo impreso. 11. Registra la venta concluida. 12. El Cliente se marcha con los artículos comprados. Cursos alternativos Línea 2: introducción del identificador inválido. Indicar error. Línea 7: el cliente no tenía suficiente dinero. Cancelar la transacción de venta.

Casos de Uso – Eventos Temporales
Evento temporal Es un evento del sistema que es gatillado por el paso del tiempo. El actor del caso de uso de un evento temporal es el tiempo. Teaching Tips Have students provide examples of temporal events (nightly download, monthly billing, etc.).

Beneficios de la Modelación de Casos de Uso
Base para identificar objetos y sus relaciones y responsabilidades de alto nivel. Visualizar el comportamiento del sistema desde el punto de vista de una persona externa. Herramienta eficaz para validar requisitos. Herramienta eficaz de comunicación. Base para un plan de prueba. Base para un manual de usuario. No additional notes.

Proceso de Modelación de Casos de Uso
Paso 1: Identificar Actores y Casos de Uso Paso 2: Construir un Diagrama de Casos de Uso Paso 3: Documentar el Curso Normal del Caso de Uso Paso 4: Definir Caso de Uso de Análisis No additional notes.

Diagrama de Contexto – Sistema de Servicio al Cliente
Member Services System Marketing Department Potential Club Warehouse Accounts Receivable Past various Inquiry Reponses various Sales Reports various Promotion Reports Subscription Offer Member Order New Subscription Promotion Subscription Renewal Resubscription Offer various Member Reports various Subscription Reports Subscription Program New Promotion Revised Packing Order Credit Status Teaching Notes Identifying use cases was introduced in Chapter 6. A good place to find potential actors and use cases is by analyzing the context model diagram of the system. Recall that a system context model illustrates the external parties that interact with the system to provide inputs and receive outputs. In doing so, it identifies the system’s scope and boundaries. Teaching Tips The figure above is a context model for the SoundStage Member Services System. Have the students find the external parties which provide inputs to the system. Does the external party initiate the input or is the input a response to a request from the system? If the external party initiates the input, it is considered an actor. Some of the inputs are self explanatory, but others may be misleading, it is always wise to confirm your findings with the system’s business analyst.

Paso 1: Identificar Actores y Casos de Usos
Potential Member Club Member Past Member Marketing Time Use Case Name SUBMIT NEW SUBSCRIPTION PLACE NEW MEMBER ORDER MAKE ACCOUNT INQUIRY MAKE PURCHASE INQUIRY MAINTAIN MEMBER ORDER SUBMIT CHANGE OF ADDRESS SUBMIT RESUBSCRIPTION SUBMIT NEW MEMBER SUBSCRIPTION PROGRAM SUBMIT PAST MEMBER RESUBSCRIPTION PROGRAM SUBMIT NEW PROMOTION GENERATE QUARTERLY PROMOTION ANALYSIS GENERATE QUARTERLY SALES ANALYSIS GENERATE QUARTERLY MEMBERSHIP ANALYSIS GENERATE ANNUAL SALES ANALYSIS GENERATE ANNUAL MEMBERSHIP ANALYSIS Use Case Description Potential member joins the club by subscribing. (“Take anu 12 CDs for one penny and agree to buy 4 more at regular club prices within two years.”) Club member places order. Club member wants to examine his or her account history. (90-day time limit) Club member inquires about his/her purchase history. (three-year time limit) Club member wants to revise an order or cancel an order. Club member changes address. (including and privacy code) Past member rejoins the club by resubscribing. Marketing establishes a new membership resubscription plan to entice new members. Marketing establishes a new membership resubscription plan to lure back former members. Marketing initiates a promotion. (Note: A promotion features specific titles, usually new, that company is trying to sell at a special price. These promotions are integrated into a catalog sent (or communicated) to all members.) Print quarterly promotion analysis report. Print annual sales analysis report. Print annual membership analysis report. Print annual sales analysis report. Print annual membership analysis report. Teaching Notes The above figure is the result of identifying use cases and actors of the previous figure.

Paso 2: Construir un Diagrama de Casos de Usos
Teaching Notes A use case model diagram can be used to graphically depict the system scope and boundaries in terms of use cases and actors. The use case model diagram for the Member Services System is shown in the above figure. It was created using Popkin Software’s System Architect and represents the relationships between the actors and use cases defined for each business subsystem. The subsystems (UML package symbol) represent logical functional areas of business processes. The partitioning of system behavior into subsystems is very important in understanding the system architecture and is very key to defining your development strategy — which use cases will be developed first and by whom.

Paso 3: Documentar curso normal del caso de uso
Documenting the Use Case Typical Course Teaching Notes The above figure was initinally presented in Chapter 6. 1. A reference to the requirement(s) in which it can be traced to. 2. A typical event course describing the use case’s major steps, from beginning to end of this interaction with the actor. 3. Alternate courses describing exceptions to the typical course of events. 4. Precondition describing the state the system is in before the use case is executed. 5. Postcondition describing the state the system is in after the use case is executed. 6. An assumptions section, which includes any nonbehavioral issues, such as performance or security, that is associated with the use case, but is difficult to model within the use case’s course of events.

Teaching Notes The above figure was initinally presented in Chapter 6. 1. A reference to the requirement(s) in which it can be traced to. 2. A typical event course describing the use case’s major steps, from beginning to end of this interaction with the actor. 3. Alternate courses describing exceptions to the typical course of events. 4. Precondition describing the state the system is in before the use case is executed. 5. Postcondition describing the state the system is in after the use case is executed. 6. An assumptions section, which includes any nonbehavioral issues, such as performance or security, that is associated with the use case, but is difficult to model within the use case’s course of events.

Referencia a los requerimientos con los cuales está relacionado. El curso común del evento que describe los pasos principales del caso del uso, desde cuando comienza hasta cuando termina la interacción con el actor. Cursos alternativos que describen excepciones al curso común del evento. Precondición que describe el estado en que debe estar el sistema para que se ejecute el caso del uso. Poscondición que describe el estado en que queda el sistema después de que se ejecuta el caso del uso. Supuestos, que incluye cualquier tópico no relacionado con el comportamiento del caso de uso, tales como rendimiento o seguridad, que está asociado al caso de uso. En general, son aspectos que son difíciles de modelar dentro del curso de eventos del caso de uso. 1 2 3 4 5 6

Tipos de Casos de Usos Caso de Uso de Extensión
Amplía la funcionalidad (curso normal) de un cierto caso de uso. Un caso de uso de extensión puede ser invocado solamente por el caso del uso que está ampliando. Caso de Uso Abstracto Contiene los cursos normales que son comunes a dos o más casos de uso originales. Un caso de uso abstracto reduce redundancia y promueve la reutilización. Teaching Notes Extension and abstract use cases are usually discovered during analysis and their main purpose is to simplify the original use cases – basically decompose the original use case into a less complex form.

Representación usando la notación de UML
No additional notes.

Casos de Uso – Relaciones
UML define tres tipos de relación en los Diagramas de Casos de Uso Comunicación

Inclusión Una instancia del Caso de Uso origen incluye también el comportamiento descrito por el Caso de Uso destino <<include>> es equivalente a <<uses>> Para la explicación de las relaciones entre casos de uso se han identificado como “caso de uso origen” y “caso de uso destino” sólo para indicar el sentido del símbolo (flecha de generalización).

Extensión El Caso de Uso origen extiende el comportamiento del Caso de Uso destino Las relaciones <<include>> y <<extend>> corresponden ambas a factorizaciones del comportamiento de un caso de uso, es decir, el caso de uso incluido y el caso de uso que extiende representan un fragmento de interacción de otro caso de uso. Sin embargo, la intensión es diferente; la relación <<include>> pretende evitar duplicación de interacciones en distintos casos de uso, la relación <<extends>> pretende describir una variación del comportamiento normal de un caso de uso, sobre todo cuando dicha variación pudiera complicar la legibilidad del caso de uso.

Paso 4: Definir Caso de Uso de Análisis
Teaching Notes Example of an analysis use case with extension and abstract use cases highlighted.

Actividades Generales del Análisis Orientado Objeto

Encontrar e Identificar Objetos del Negocio
Paso 1: Encontrar objetos potenciales Subrayar (o destacar) los sustantivos del caso de uso Paso 2: Seleccionar los objetos propuestos Quitar los sustantivos que representan: Sinónimos Sustantivos fuera del alcance del sistema Sustantivos que son roles que no tienen un comportamiento único o que son externos Sustantivos confusos que necesitan ser reenfocados Sustantivos que son en realidad acciones o cualidades Teaching Notes Using use cases as a source for finding objects is a popular approach for object identification.

Caso de uso con Sustantivos Subrayados
No additional notes

Objetos Potenciales Extraídos desde el caso de uso
POTENTIAL OBJECT LIST Accounts Receivable Department Amount Due Club Member Credit Card Information Credit Problem Notice Credit Status File Marketing Department Member Address Member Order Member Phone Number Member Services Department Member Services System Order Order Confirmation Notice Order Sales Tax Order Status Order Subtotal Ordered Product Ordered Product Information Ordered Product Quantity Past Member Payments Potential Member Product Product Inventory Product Number Street Address Transaction Warehouse Warehouse Packing Order Extraídos desde el caso de uso Análisis de Objetos Potenciales Teaching Tips Have students discuss which of the potential objects should be selected.

x / POTENTIAL OBJECT LIST REASON Accounts Receivable Department
Amount Due Club Member Credit Card Information Credit Problem Notice Credit Status File Marketing Department Member Address Member Order Member Phone Number Member Services Department Member Services System Order Order Confirmation Notice Order Sales Tax Order Status Order Subtotal Ordered Product Ordered Product Information Ordered Product Quantity Past Member Payments Potential Member Product Product Inventory Product Number Street Address Transaction Warehouse Warehouse Packing Order Not relevant for current project Attribute of “MEMBER ORDER” Type of “MEMBER” Attribute of “MEMBER” Potential Interface item to be addressed in object-oriented design “MEMBER ORDER” Another name for “MEMBER ORDER” “MEMBER ORDERED PRODUCT” Unclear noun Attribute of “MEMBER ORDERED PRODUCT” Type of “TRANSACTION” “PRODUCT” Attribute of “PRODUCT” “TRANSACTION” REASON x / No additional notes.

Resultados del Análisis
PROPOSED OBJECT LIST CLUB MEMBER MEMBER ORDER MEMBER ORDERED PRODUCT PAST MEMBER PAYMENT POTENTIAL MEMBER PRODUCT TRANSACTION AGREEMENT AUDIO TITLE MERCHANDISE GAME TITLE PROMOTION RETURN TITLE VIDEO TITLE -- PLUS -- Teaching Notes Additional objects were included that are part of the case study but were not identified in the use case. These additional objects are introduced here because they appear in later diagrams.

Actividades Generales delAnálisis Orientado Objeto

Diagramas que muestran la estructura del sistema
Diagrama de clases Muestra las clases de objetos de las que está compuesto el sistema, así como las relaciones que existen entre ellos. Diagrama de objetos Similar al anterior, pero muestra instancias individuales de cada clases. Class diagrams (structure) depict the system’s object structure. They show object classes that the system is composed of as well as the relationships between those object classes. Object diagrams (structure) are similar to class diagrams, but instead of depicting object classes, it models actual object instances—showing the current values of the instance’s attributes. The object diagram provides the developer with a “snapshot” of the system’s objects at one point in time. This diagram is not used as often as a class diagram, but when used, can help a developer better understand the structure of the system.

Objetos, Atributos, e Instancias
Es algo (persona, lugar, cosa, o evento) que es visto, tocado, o percibido de alguna manera, y sobre el cual los usuarios almacenan datos y le asocian un cierto comportamiento. Atributos Datos que representan características de interés de un objeto. Instancia Una instancia (o instancia de un objeto) está formada por los valores para cada uno de los atributos que describen un objeto específico. Teaching Notes There are several concepts that object-oriented analysis is based on. Some of these concepts require a totally new way of thinking about systems and the development process. These concepts have presented a formidable challenge to veteran developers who must relearn how they have traditionally viewed systems. Object-oriented approaches to systems development are concerned with identifying attributes that are of interest regarding an object. It is important to note that with advances in technology, attributes have evolved to include more than simple data characteristics as represented in the previous example. Today, objects may include newer attribute types, such as a bitmap or a picture sound, or even video. Teaching Tips Have students provide examples of objects and their attributes that exist in the classroom.

Objetos, Atributos, e Instancias
412209: Customer customer number = last name = Bentley first name = Lonnie home phone = street = 2625 Darwin Dr. city = West Lafayette state = Indiana zip code = 47906 etc. : Book ISBN = type = textbook title = Systems Analysis & Design Methods copyright = 1996 : Book ISBN = type = workbook title = Projects and Cases to Accompany SADM (a) (b) Teaching Notes Figure (a) depicts the symbol for representing an object instance using the UML modeling notation. An object is represented using a rectangle. The name of the object instance and its classification are underlined and appear at the top of the symbol. The attribute values for the object instance are optionally recorded within the symbol and are separated from the object name with a line. The name of an object instance is the value of the attribute that uniquely identifies it. In figure (a) the attribute customer number, whose value is , uniquely identifies that instance of customer. Thus, is the name of the object instance and customer is its classification. In figure (b) above, the textbook and workbook objects represent thing-objects that have similar attributes and behavior. For example, similar attributes might be ISBN NUMBER, TYPE OF BOOK, TITLE, COPYRIGHT DATE, etc. Likewise, they have similar behavior, such as being able to OPEN and CLOSE.

Método Se entiende por comportamiento a todo aquello que el objeto pueda hacer y que corresponde a funciones que actúan sobre los datos (atributos) del objeto. En el contexto de orientación a objetos, se utiliza el concepto de método (o servicio) para referirse al comportamiento de un objeto.

Encapsulación Es la agrupación de varios elementos en una unidad.
Los atributos y métodos se encapsulan en el objeto. La única forma de acceder a los atributos de un objeto es a través de sus métodos. Teaching Notes In encapsulation, both attributes and behavior of the object are packaged together. The only way to access an object's attributes is through that object’s behaviors. No other object may perform that object’s behavior. Teaching Tips Have students identify the behaviors of a door, window, or VCR.

Clases de Objetos Es un conjunto de objetos que tienen en común los mismos atributos y el mismo comportamiento. Las clases también se denominan clases de objetos. Open() Close() ISBN type title copyright Book Customer customer number last name first name home phone street city state zip code etc. changeAddress() Teaching Notes In UML an object class is represented using a rectangle symbol. The rectangle is divided into three portions. The top portion contains the name of the class. The middle portion contains the names of the attributes. The lower portion contains the behaviors (or methods). To simplify the appearance of a diagram, or to specify more details about a class, class symbols can be drawn without methods or attributes, or the attribute portion can be expanded to include data types, lengths, etc. The appearance depends on what the author of the diagram is intending to communicate.

Herencia Describe el mecanismo mediante el cual los atributos y/o métodos definidos para una clase de objetos puede ser heredado o reutilizado por otra clase de objetos. Generalización/Especialización Es una técnica donde los atributos y métodos que son comunes a varios tipos de clases de objetos se agrupan en su propia clase, llamada supertipo. Los atributos y métodos de la clase de objetos supertipo son heredados a las clases de objetos originales. Teaching Notes Inheritance is a critical concept of OO. In fact for a programming language or DBMS to be considered OO, it must support inheritance. In inheritance, the child class inherits the attributes and methods from its parent class(s).

Supertipos y Subtipos Clase Supertipo
Es una clase de objetos cuyas instancias almacenan atributos que son comunes a una o más clases subtipos. Clase Subtipo Es una clase de objetos cuyas instancias heredan algunos atributos comunes de una clase supertipo, y luego agregan otros atributos que son únicos para las instancias del subtipo. Teaching Notes The class supertype will have one or more one-to-one relationships to object class subtypes. These relationships are sometimes called “IS A” relationships (or “WAS A” or “COULD BE A”) because each instance of the supertype “is also an” instance of one or more subtypes.

Supertipos y Subtipos Clase Persona (supertipo) Clase Alumno (subtipo)
Clase Profesor Alumno A Alumno B Alumno C Profesor A Profesor B Teaching Notes The class supertype will have one or more one-to-one relationships to object class subtypes. These relationships are sometimes called “IS A” relationships (or “WAS A” or “COULD BE A”) because each instance of the supertype “is also an” instance of one or more subtypes.

Generalización/Especialización en UML
walk() jump() talk() sleep() eat() etc.() last name first name birth date gender Person enroll() displayGPA() GPA classification Student lecture() rank Teacher Puntas de flechas indican relación de generalización/especialización Teaching Tips Have students identify what attributes and methods are inherited by the STUDENT and TEACHER classes.

Relaciones entre clases de objetos
Es una asociación natural de negocios que existe entre una o más clases de objetos. 0..* Customer Order Places Teaching Notes Objects and classes do not exist in isolation. The things they represent interact with and impact one another to support the business mission. An object/class relationship is graphically illustrated in UML as a connecting line between two classes. This relationship is commonly referred to as an association. The line is labeled with a verb phrase that describes the association. All associations are implicitly bidirectional, meaning that they can interpreted in both directions. The figure above shows the complexity or degree of each association. For example, in the above business assertions, we must also answer the following questions: Must there exist an instance of CUSTOMER for each instance of ORDER? Yes! Must there exist an instance of ORDER for each instance of CUSTOMER? No! How many instances of ORDER can exist for each instance of CUSTOMER? Many! How many instances of CUSTOMER can exist for each instance of ORDER? One!

Multiplicidad Define como varias instancias de una clase de objetos puede ser asociada con una sola instancia de otra clase de objetos. Teaching Notes Because all associations are implicitly bidirectional, multiplicity must be defined in both directions for every association.

Notación de Multiplicidad en UML
Multiplicity Works for 0..1 Has 0..* Makes UML Notation Association with Multiplicity Association Meaning Exactly 1 1 or leave blank Department Employee An employee works for one and only one department. Zero or one Spouse An employee has either one or no spouse. Zero or more * Payment Customer A customer can make no payment up to many payments. One or more 1..* Course University Offers A u niversity offers at least 1 course up to many courses. Specific range 7..9 Game Team scheduled A team has either 7, 8, or 9 games No additional notes.

Ejemplo en UML de una relación de agregación compuesta
Book Cover Table of Contents Chapter Index Page Paragraph Word 1 1..* 0..1 0..* Diamante sólido indica relación de agregación compuesta Teaching Notes Sometimes objects/classes are made up of other objects/classes. This type of relationship is called aggregation. It is also sometimes referred to as “whole-part” or “part-of” relationships. Aggregation relationships do not support inheritance. Their benefit lies in the ability to send a message to the parent class and that message is automatically applied to all the child classes. Teaching Tips Have students provide other examples of objects where aggregation relationships are appropriate (car – or any bill of material, church, order-line item, etc.).

Ejemplo en UML de una relación de agregación compartida
Team Player 0..* Diamante hueco indica una relación de agregación compartida No additional notes.

Mensaje Se pasa un mensaje cuando un objeto invoca uno o más métodos de otro objeto para requerir información o producir una acción. Customer add order modify order delete order display status etc. order number order date order status Order display order status of order 23161 MENSAJE SOLICITADO (contiene nombre del método solicitado y los atributos requeridos por la clase ORDER) Teaching Notes The object sending a message does not need to know how the receiving object is organized internally or how the behavior is to be accomplished, only that it responds to the request in a well-defined way. A message can be sent only between two objects that have an association between them.

Construcción de un Diagrama de Clases
Paso 1: Identificar Asociaciones y Multiplicidad Subrayar (o destacar) los sustantivos del caso de uso Paso 2: Identificar relaciones de Generalización /Especialización Paso 3: Identificar relaciones de Agregación Paso 4: Preparar el diagrama de Clases Teaching Notes It is very important that the analyst not only identify relationships that are obvious or recognized by the users. On way to help ensure that possible relationships are identified is to use a object/class matrix. This matrix lists the objects/class as column headings as well as row headings. The matrix can then be used as a check list to ensure that each object/class appearing on a row is checked against each object/class appearing in a column for possible relationships. The name of the relationship and the multiplicity can be recorded directly in the intersection cell of the matrix. Generalization/Specialization relationships may be discovered by looking at the class diagram. Do any associations exist between two objects that have a one-to-one multiplicity? If so, can you say the sentence “object X is a object Y” and it be true? If it is true, you may have a generalization/specialization relationship. Also look for objects which have common attributes and behaviors. It may be possible to combine the common attributes and behaviors into a new super-object. Why do we want generalization/specialization relationships? It allows us to take advantage of inheritance which facilitates the reuse of objects and programming code. Aggregation relationships are asymmetric, in that object B is part of Object A but, object A is not part of object B. Aggregation relationships do not imply inheritance, in that object B does not inherit behavior or attributes from object A. Aggregation relationships propagate behavior in that behavior applied to the whole is automatically applied to the parts.

Diagrama de Clases del Sistema de Servicio a Clientes
<<actor>> Club Member Member-Date-Of-Last-Order Member-Daytime-Phone-Number Member-Credit-Card-Expire-Date Member-Credit-Card-Number Member-Credit-Card-Type Member-Balance-Due Member-Bonus-Balance-Available Audio-Category-Preference Audio-Media-Preference Date-Enrolled -Address Game-Category-Preference Game-Media-Preference Number-Of-Credits-Earned Privacy-Code Video-Category-Preference Video-Media-Preference persistent Member Order Order-Number Order-Creation-Date Order-Fill-Date Shipping-Address-Name Shipping-Street-Address Shipping-City Shipping-State Shipping-Zip-Code Shipping-Instructions Order-Sub-Total Order-Sales-Tax Order-Shipping-Method Order-Shipping-&-Handling-Cost Order-Status Order-Prepaid-Amount Order-Prepayment-Method Product Product-Number UPC- Quantity-In-Stock Product-Type Suggested-Retail-Price Default-Unit-Price Current-Special-Unit-Price Current-Month-Units-Sold Current-Year-Units-Sold Total-Lifetime-Units-Sold Video Title Producer Director Video-Category Video-Sub-Category Closed-Captioned Language Running-Time Video-Media-Type Video-Encoding Screen-Aspect MPA-Rating-Code Audio Tilte Artist Audio-Category Audio-Sub-Category Number-Of-Units-In-Package Audio-Media-Code Content-Advisory-Code Transaction Transaction-Reference-Number Transaction-Date Transaction-Type Transaction-Description Transation-Amount Member Member-Number Member-Name Member-Status Member-Street-Address Member-PO-Box Member-City Member-State Member-Zip-Code Agreement Agreement-Number Agreement-Expire-Date Agreement-Active-Date Fulfillment-Period Required-Number-Of-Credits Game Title Manufacturer Game-Category Game-Sub-Category Game-Platform Game-Media-Type Number-Of-Players Parent-Advisory-Code Title Title-Of-Work Title-Cover Catalog-Description Copyright-Date Entertainment-Company Credit-Value Member Ordered Product Quantity-Ordered Quantity-Shipped Quantity-Backordered Purchase-Unit-Price Credits-Earned Merchandise Merchandise-Name Merchandise-Description Merchandise-Type Unit-of-Measure Promotion Promotion-Number Promotion-Release-Date Promotion-Status Promotion-Type Potential Member Past Member Expiration-Date Return 1..* 1 binds 0..* Conduct s Has purchased 0..1 Generate Feature Sold as Places Sells No additional notes.

Actividades Generales del Análisis Orientado Objeto

Diagramas que describen el estado de los objetos
Diagramas de Estados Los diagramas de estados se utilizan para modelar el comportamiento dinámico de un objeto particular. Ilustran el ciclo de vida de un objeto – los varios estados que un objeto puede asumir y los eventos que causan la transición del objeto de un estado a otro. State diagrams (state) are used to model the dynamic behavior of a particular object. They illustrate an object’s life cycle—the various states that an object can assume and the events that cause the object to transition from one state to another. Activity diagrams (state) are used to graphically depict the sequential flow of activities of either a business process or a use case. They also can be used to model actions that will be performed when an operation is executing as well as the results of those actions.

Ejemplo de Estados de un Objeto
Posibles “estados” del Trasbordador Espacial estado "PRE-LANZAMIENTO" “VUELO" “Despegue" Teaching Notes All objects are said to have state—the value of the attributes at one point in time. An object changes state when something happens or when the value of one of its attributes changes. This change in state is triggered by an event. Draw your attention to the figure above. The space shuttle resting on the launching pad is shown in a state of Pre-Launch. After the shuttle takes off (an event) it changes state (state transition) and while it is in the air it is in a state of Flight. We could have shown additional states such as Landed, Checkout, or Refurbish if the requirements specified it. Many of the objects in business systems have complex behaviors or go through many states and types of state.

Diagrama de estados Modela el ciclo de vida de un solo objeto.
Representa los diversos estados que un objeto puede tener, los eventos que hacen que el objeto cambie de estado en el tiempo, y las reglas que gobiernan la transición del objeto entre los estados. Especifica de qué estado de un objeto es posible la transición a otro estado. Los diagramas de estados no son requeridos para todos los objetos. Típicamente, un diagrama de estados se construye solamente para aquellos objetos que tienen estados claramente identificables y un comportamiento complejo.

Diagrama de estados – teléfono
Ocioso Activo descolgar auricular colgar auricular Estado inicial Transición Evento

Diagrama de estados – casos de uso
Una aplicación útil de este tipo de diagramas consiste en describir la secuencia permitida de eventos externos que reconoce y maneja un sistema dentro del contexto de un caso de uso. Es útil para describir el orden legal de los eventos externos.

Diagrama de estados – casos de uso
Ejemplos: En el caso Comprar Productos de la aplicación del punto de venta, no está permitido efectuar la operación efectuarPagoConTarjeta mientras no haya ocurrido el evento terminarVenta. En el caso Procesar Documento en un procesador de texto, no está permitido efectuar la operación Guardar en Archivo mientras no haya ocurrido el evento Crear Archivo Nuevo o Abrir Archivo.

Diagrama de estados – comprar productos
EnEsperadelaVenta EnEsperadelPago efectuarPago Evento del sistema ( externo) IntroduciendoProductos introducirProducto terminarVenta

Diagrama de estados del Sistema de Servicio a Clientes
Order Shipped Order Released Order Filled Order Invoiced Pending In Process Order Backordered Order Closed Member Order final state Member Order initial state Order pending awaiting payment or additional member information Order rejected based on Member's past history Member order archived after 90 days Invoice sent to member for payment Response received from member Order released to the warehouse Order shipped to club member Order filled by the warehouse Not all product available Final payment received Order submitted Product received Teaching Notes A state diagram models the life cycle of a single object. It depicts the different states an object can have, the events that cause the object to change state over time, and the rules that govern the object’s transition between states. In other words, it specifies from which state an object is allowed to transition to another state. State diagrams are not required for all objects. Typically, a state diagram is only constructed for those objects that clearly have identifiable states and complex behavior.

Diagramas que describen el estado de los objetos
Diagramas de Actividades Los diagramas de actividades se utilizan para representar gráficamente el flujo secuencial de actividades de un proceso de negocios o un caso de uso. También pueden ser utilizados para modelar las acciones que serán realizadas cuando una operación se está ejecutando así como los resultados de dichas acciones. State diagrams (state) are used to model the dynamic behavior of a particular object. They illustrate an object’s life cycle—the various states that an object can assume and the events that cause the object to transition from one state to another. Activity diagrams (state) are used to graphically depict the sequential flow of activities of either a business process or a use case. They also can be used to model actions that will be performed when an operation is executing as well as the results of those actions.

Diagrama de Actividades
Input Request Route to Manager Evaluate Need Check Budget [need] [budget] [no need] [no budget Disapprove Request Approve Purchasing Agent Teaching Notes Activity diagrams are similar to flowcharts in that they graphically depict the sequential flow of activities of either a business process or a use case. They are different from flowcharts in that they provide a mechanism to depict activities that occur in parallel. Because of this they are very useful to model actions that will be performed when an operation is executing as well as the results of those actions—such as modeling the events that cause windows to be displayed or closed. Activity diagrams are flexible in that they can be used during analysis and design.

Diagramas que describen el comportamiento de los objetos
Diagramas de Secuencia Los diagramas de secuencia representan gráficamente cómo los objetos interactúan entre sí vía mensajes en la ejecución un caso de uso. Ilustran cómo se envían y reciben los mensajes entre los objetos y en qué secuencia. Sequence diagrams (behavior) graphically depict how objects interact with each other via messages in the execution of a use case or operation. They illustrate how messages are sent and received between objects and in what sequence. Collaboration diagrams are similar to sequence diagrams but do not focus on the timing or “sequence” of messages. Instead, they present the interaction (or collaboration) between objects in a network format.

Eventos y operaciones del sistema
Evento del sistema Es un hecho externo que un actor realiza y produce una entrada al sistema. Operación del sistema Es una acción que el sistema ejecuta en respuesta a una evento del sistema. Los eventos de un sistema (y sus operaciones asociadas) deben expresarse en el nivel de propósito y no en el nivel del medio físico de entrada o de elementos de la interfaz.

Eventos y operaciones del sistema (2)
Ejemplo: Cuando un cajero genera un evento introducirProducto, causa la ejecución de la operación introducirProducto. El nombre del evento y de la operación son idénticos; la distinción reside en que el evento es el estímulo y la operación es la repuesta (lo mismo sucede con los mensajes y los métodos).

Registro de las operaciones de un sistema
Para determinar el conjunto de operaciones requeridas del sistema se identifican sus eventos. Cuando se utilizan parámetros, las operaciones son las siguientes: IntroducirProducto(CUP, Cantidad) TerminarVenta() EfectuarPago(monto)

Diagrama de Secuencia – Comprar Productos
Identificar eventos del sistema: Primero debemos determinar los actores que interactúan directamente con el sistema de software. El cliente interactúa con el cajero, pero no directamente con el sistema TPDV; esto sólo lo hace el cajero. Por tanto, el cliente no es un generador de eventos del sistema, sólo el cajero lo es.

Diagrama de Secuencia – Comprar Productos
Curso normal de los eventos en el caso Comprar Productos : Cajero :Sistema 1: introducir Producto(CUP, cantidad) 2: terminarVenta() 3: efectuarPago(monto) Sistema como caja negra Evento del sistema Inicia una operación de sistema Actor

Diagrama de Secuencia También mejora la claridad si el nombre de un evento del sistema comienza con un verbo (agregar, introducir, terminar, efectuar), ya que recalca que los eventos están orientados a comandos. Así, terminarVenta es preferible a OprimaTeclaEnter porque capta mejor el propósito de la operación: mantiene un carácter abstracto y no se pronuncia respecto a las decisiones de diseño sobre cuál interfaz sirve para capturar el evento del sistema.

Diagrama de Secuencia En cuanto a expresar las operaciones en el nivel de propósito, se debe tratar de alcanzar el nivel más alto o la meta final para asignar nombre a la operación. Por ejemplo, respecto a la operación que captura el pago: IntroducirImporteOfrecido(monto) – deficiente IntroducirPago(monto) – mejor EfectuarPago –mejor aún

verify member (member number)
Diagrama de Secuencia a Product a Member Order a Member Ordered Product an Order Processor a Club Member display member information validate item create item enter item (product number) select new order update address (address) verify member (member number) Teaching Notes The UML offers two types of diagrams (Sequence and Collaboration) to model detailed object interactions. The figure above is read from top to bottom, following the logic of the use case. Each object referenced in the use case is symbolized by a vertical line. The behaviors or operations which each object needs to fulfill an obligation is represented by a box. These boxes represent program code. The arrows between the lines represent interactions or messages being sent to a particular object to invoke one of its operations to satisfy a request.

Diagrama de Secuencia Los diagramas de secuencia se utilizan para modelar la lógica de los escenarios de uso. Un escenario de uso es la descripción de una manera potencial en que se utilizará el sistema. Los diagramas de secuencia modelan de una manera visual el flujo de la lógica dentro de un sistema, permitiendo tanto documentar como validar la lógica subyacente. Se utilizan tanto para el análisis como para el diseño. Sequence diagrams are used to model the logic of usage scenarios. A usage scenario is exactly what its name indicates – the description of a potential way that your system is used. The logic of a usage scenario may be part of a use case, perhaps an alternate course. It may also be one entire pass through a use case, such as the logic described by the basic course of action or a portion of the basic course of action plus one or more alternate scenarios. It may also be a pass through the logic contained in several use cases, for example a student enrolls in the university then immediately enrolls in three seminars. For example, Figure 2-18 models the basic course of action for the "Enroll in Seminar" use case. Sequence diagrams model the flow of logic within your system in a visual manner, enabling you to both document and validate your logic, and are commonly used for both analysis and design purposes.

Diagrama de Secuencia La lógica de un escenario de uso puede describir: Un caso de uso; la lógica descrita por el curso normal de los eventos o una porción de éste, más unos o más escenarios alternativos. Parte de un caso de uso, quizás un curso alternativo. Un conjunto de paso con la lógica contenida en varios casos de uso. Por ejemplo, un alumno se inscribe en la universidad y además se inscribe inmediatamente en tres cursos. Sequence diagrams are used to model the logic of usage scenarios. A usage scenario is exactly what its name indicates – the description of a potential way that your system is used. The logic of a usage scenario may be part of a use case, perhaps an alternate course. It may also be one entire pass through a use case, such as the logic described by the basic course of action or a portion of the basic course of action plus one or more alternate scenarios. It may also be a pass through the logic contained in several use cases, for example a student enrolls in the university then immediately enrolls in three seminars. For example, Figure 2-18 models the basic course of action for the "Enroll in Seminar" use case. Sequence diagrams model the flow of logic within your system in a visual manner, enabling you to both document and validate your logic, and are commonly used for both analysis and design purposes.

Diagrama de Secuencia

Elementos de un Diagrama de Secuencia
Los rectángulos en la parte superior del diagrama representan objetos, clases, actores, o casos de uso. Objetos y Clases Dado que es posible enviar mensajes tanto a objetos como a clases, tiene sentido incluir tanto a objetos como a clases en los diagramas de secuencia. Los objetos responden a los mensajes a través de la llamada a una operación. Las clases lo hacen a través de la llamada a una operación estática. Actores Los actores inician y tienen una participación activa en los escenarios de uso. The boxes across the top of the diagram represent classifiers or their instances, typically use cases, objects, classes, or actors. Because you can send messages to both objects and classes, objects respond to messages through the invocation of an operation and classes do so through the invocation of static operations, it makes sense to include both on sequence diagrams. Because actors initiate and take an active part in usage scenarios they are also included in sequence diagrams. Objects have labels in the standard UML format “name: ClassName” where “name” is optional (objects that have not been given a name on the diagram are called anonymous objects). Classes have labels in the format "ClassName," and actors have names in the format "Actor Name" – both UML standards as well. For example, in Figure 2-18 you see that the Student actor has the name "A Student" and is labeled with the stereotype <<actor>>.

Para los objetos, clases y actores se utilizan etiquetas estándar en el formato UML: Objetos: “nombre:NombreDeLaClase” Donde “nombre” es opcional (los objetos a los que no se les da un nombre en el diagrama se llaman objetos anónimos). Clases: “NombreDeLaClase” Actores: “NombreActor” Objects have labels in the standard UML format “name: ClassName” where “name” is optional (objects that have not been given a name on the diagram are called anonymous objects). Classes have labels in the format "ClassName," and actors have names in the format "Actor Name" – both UML standards as well. For example, in Figure 2-18 you see that the Student actor has the name "A Student" and is labeled with the stereotype <<actor>>.

Ejemplo: Cliente Objects have labels in the standard UML format “name: ClassName” where “name” is optional (objects that have not been given a name on the diagram are called anonymous objects). Classes have labels in the format "ClassName," and actors have names in the format "Actor Name" – both UML standards as well. For example, in Figure 2-18 you see that the Student actor has the name "A Student" and is labeled with the stereotype <<actor>>.

Las líneas discontinuas que cuelgan de los rectángulos se llaman líneas de vida del objeto, y representan la vida del objeto durante el escenario que está siendo modelado. Los rectángulos largos y finos en las líneas de vida son rectángulos de invocación a métodos, e indican que operación se debe ejecutar en el objeto/clase que está recibiendo el mensaje. The dashed lines hanging from the boxes are called object lifelines, representing the life span of the object during the scenario being modeled. The long, thin boxes on the lifelines are method-invocation boxes that indicate that processing is being performed by the target object/class to fulfill a message. The "X" at the bottom of a method-invocation box is a UML convention to indicate that an object has been removed from memory, typically the result of receiving a message with the stereotype of <<destroy>>. Messages are indicated as labeled arrows, when the source and target of a message is an object or class the label is the signature of the method invoked in response to the message. However, if either the source or target is a human actor then the message is labeled with brief text describing the information being communicated.

La "X" en la parte inferior de un rectángulo de invocación es una convención de UML para indicar que un objeto ha sido eliminado de la memoria, típicamente como resultado de recibir un mensaje con el estereotipo <<destroy>>. Los mensajes se indican como flechas etiquetadas Cuando el emisor y el receptor de un mensaje es un objeto o una clase, la etiqueta corresponde al método que se invocará como respuesta al mensaje. Si el emisor o el receptor es un actor humano entonces el mensaje se etiqueta con un texto breve que describe la información que está siendo comunicada. The dashed lines hanging from the boxes are called object lifelines, representing the life span of the object during the scenario being modeled. The long, thin boxes on the lifelines are method-invocation boxes that indicate that processing is being performed by the target object/class to fulfill a message. The "X" at the bottom of a method-invocation box is a UML convention to indicate that an object has been removed from memory, typically the result of receiving a message with the stereotype of <<destroy>>. Messages are indicated as labeled arrows, when the source and target of a message is an object or class the label is the signature of the method invoked in response to the message. However, if either the source or target is a human actor then the message is labeled with brief text describing the information being communicated.

Diagramas que describen el comportamiento de los objetos
Diagramas de Colaboración Los diagramas de colaboración son similares a los diagramas de secuencia, pero no se centran en la sincronización o "secuencia" de mensajes, si no que presentan la interacción (o colaboración) entre los objetos en un formato de red. Sequence diagrams (behavior) graphically depict how objects interact with each other via messages in the execution of a use case or operation. They illustrate how messages are sent and received between objects and in what sequence. Collaboration diagrams are similar to sequence diagrams but do not focus on the timing or “sequence” of messages. Instead, they present the interaction (or collaboration) between objects in a network format.

Diagrama de Colaboración
El diseño orientado a objetos tiene por objetivo definir las especificaciones lógicas del software que cumplan con los requisitos funcionales. Un paso esencial en esta fase es la asignación de responsabilidades entre los objetos y mostrar como interactúan a través de mensajes. El diagrama de colaboración presenta el flujo de mensajes entre las instancias y la invocación de métodos. El diseño orientado a objetos tiene por objetivo definir las especificaciones lógicas del software que cumplan con los requisitos funcionales. Un paso esencial en esta fase es la asignación de los responsabilidades entre los objetos y mostrar como interactúan a través de mensajes. El diagrama de colaboración presenta el flujo de mensajes entre las instancias y la invocación de métodos.

Diagrama de Colaboración – juego de dados
La figura muestra gráficamente los elementos esenciales del juego, enviando mensajes a las instancias de las clases Jugador y Dado. :Jugador d1:Dado jugar() 1:r1:= lanzar() d2:Dado 2:r2:= lanzar()

Diagramas de Colaboración y de Secuencia
Los diagramas de colaboración describen las interacciones entre los objetos en un formato de grafo o red: Los diagramas de secuencia describen las interacciones en una especie de formato de cerca o muro: Instancia1 : ClaseA Instancia2 : ClaseB 1: mensaje2() 2: mensaje3() mensaje1() Instancia1 : ClaseA Instancia2 : ClaseB mensaje2() mensaje3() mensaje1()

Diagramas que describen la implementación de los objetos
Diagramas de Componentes Los diagramas componentes se utilizan para representar gráficamente la arquitectura física del sistema. Pueden ser utilizados para demostrar cómo el código de programación se divide en módulos (o componentes). Component diagrams (implementation) are used to graphically depict the physical architecture of the system. They can be used to show how programming code is divided into modules (or components). Deployment diagrams (implementation) describe the physical architecture of the hardware and software in the system. They depict the software components, processors, and devices that make up the system’s architecture.

Diagrama de Componentes
Client Source Code Comment (client.exe) Drawing Library (drawing.dll) dependency Teaching Notes Component diagrams are implementation type diagrams and are used to graphically depict the physical architecture of the software of the system. They can be used to show how programming code is divided into modules (or components) and depict the dependencies between those components.

Diagramas que describen la implementación de los objetos
Diagramas de Despliegue Los diagramas del despliegue describen la arquitectura física del hardware y software en el sistema. Representan las componentes de software, los procesadores, y los dispositivos que forman la arquitectura del sistema. Component diagrams (implementation) are used to graphically depict the physical architecture of the system. They can be used to show how programming code is divided into modules (or components). Deployment diagrams (implementation) describe the physical architecture of the hardware and software in the system. They depict the software components, processors, and devices that make up the system’s architecture.

Diagrama de Despliegue
Application Server - Compaq PIII 500 Client Workstation HP Kayak XU-400 Database Server - Compaq PIII 500 SAP R/3 Comment Client Source Code (client.exe) Oracle 8 TCP/IP Teaching Notes Deployment diagrams are also implementation type diagrams that describe the physical architecture of the hardware and software in the system. They depict the software components, processors, and devices that make up the system’s architecture.

UML José Vargas Mery.

Presentaciones similares

Presentación del tema: "UML José Vargas Mery."— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

UML José Vargas Mery.

Presentaciones similares

Presentación del tema: "UML José Vargas Mery."— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback