1 Seminar The Unified Modeling Language (UML)

2 Code as a representation of a piece of softwarepackage codemodel; public class Guitarist extends Person implements MusicPlayer { Guitar favoriteGuitar; public Guitarist (String name) {super(name);} // A couple of local methods for accessing the class's properties public void setInstrument(Instrument instrument) { if (instrument instanceof Guitar) { this.favoriteGuitar = (Guitar) instrument; }else { System.out.println("I'm not playing that thing!"); } public Instrument getInstrument( ) {return this.favoriteGuitar;} It represents only the logic of its behavior, nothing else. It is caught by humans very slowly It does not help to reuse the design decisions El código es un ejemplo extremo de lenguaje para describir un programa. En él no se ha realizado ninguna abstracción. Cada línea de código contiene los detalles de como el programa debe trabajar. Problemas que tiene el uso del código como medio de descripción son: El código ha sido escrito para ser interpretado por el compilador, y en consecuencia contiene muchos detalles que sólo tienen interés para él y que hacen compleja su interpretación por un diseñador humano. El código describe únicamente en el software en sí, e ignora el resto del sistema. Aún pensando que el código es una definición completa y no ambigua de lo que el software hace, no nos indica el como se utiliza y quien debe utilizarlo. Con el código se pierde la visión completa del software. El código no es un medio adecuado para intercambiar ideas entre programadores y diseñadores humanos, los cuales deben de inventar otros recursos para comunicarse. El código debe interpretándose leyendo un texto, y esto es muy lento para las personas. Si lo que se está haciendo es diseñar el sistema, su representación como código dificulta su posibilidad de reutilización en otros sistemas, posiblemente desarrollados en otros lenguajes.

3 Natural language for representing softwareGuitarist is a class that contains six members: one static and five non-static. Guitarist uses, and so needs an instance of, Guitar; however, since this might be shared with other classes in its package, the Guitar instance variable, called favoriteGuitar, is declared as default. Five of the members within Guitarist are methods. Four are not static. One of these methods is a constructor that takes one argument, and instances of String are called name, which removes the default constructor. Three regular methods are then provided. The first is called setInstrument, and it takes one parameter, an instance of Instrument called instrument, and has no return type. The second is called getInstrument and it has no parameters, but its return type is Instrument. The final method is called play. The play method is actually enforced by the MusicPlayer interface that the Guitarist class implements. The play method takes no parameters, and its return type is void. It is ambiguous and even confusing It takes a while to catch the idea and reason about it It is difficult to process. En el extremo opuesto al código se encuentra la descripción del software mediante lenguaje natural. Este es informal y no sigue una notación bien definida y concensuada. Los posteriores lectores de esta descripción pueden entender muy diferentes interpretaciones de lo que representan. También es textual, por lo que su interpretación por un humano es muy lenta y tediosa.

4 Visual models for representing a piece of softwareEn la figura se muestra una vista de la descripción UML de una sección de código. Si conoce el lenguaje UML y la semántica de sus símbolos, una simple ojeada del grafico da una visión general de lo que describe, y además proporciona las vías por las que acceder a una información mas detallada de cualquier elemento (incluido sus códigos). Esto se debe a que el UML es un lenguaje formal: un lenguaje sencillo con un conjunto de reglas bien definidas que evitan la ambigüedad. Cualquier persona con conocimientos de UML interpretaría este diagrama de la misma forma.

5 Unified Modeling LanguageThe Unified Modeling Language (UML) is a conceptual modeling language based on an object oriented methodology. The objective of UML is enabling the representation of models for systems in general but in particular for software applications. A model is a set of abstractions that represents a system in order to cope with its complexities in a given domain. A UML model is formed by : A set of modeling elements and rules that define the structure and functionality of the system collected in a common repository. The presentation of those concepts by means of multiple graphical views, which formalize the creation and edition of the models according to the rules of the language and the purpose of the model. El Lenguaje de Modelado Unificado (UML) es un lenguaje basado en la metodología orientada a objetos creado por el Object Management Group (OMG) con la intención de convertirse en un estándar para el modelado de aplicaciones software, tanto a efectos de servir de base de la ingeniería software, servir de método de intercambio de ideas entre los equipos que desarrollan software y como base a las herramientas que utilizan. UML es un lenguaje de modelado universal con capacidad de describir cualquier tipo de sistema, sin embargo, su desarrollo semántico ha sido específicamente desarrollado para el modelado de aplicaciones software. El objetivo de UML es permitir al diseñador formular un modelo del sistema y por modelo se entiende la definición de un conjunto de abstracciones semánticas que permiten describir simbólicamente los conceptos estructurales, de comportamiento y funcionales que se proponen para el sistema. En UML los elementos que constituyen el modelo se definen de forma integrada y coherente dentro de una única base de datos. El modelo se presenta a través de múltiples vistas gráficas, que presentan parcialmente diferentes aspecto de la semántica del modelo. Las vistas son el recurso principal para introducir, editar y presentar el modelo. El conjunto de todas las vistas son parte o la descripción semántica completa del sistema.

6 Advantages of UML It is based on a metamodel with a defined semantics.Proposes a concrete graphical notation easy to use and learn. It is an international standard supported and maintained by a solid standardization board, the Object Management Group (OMG). It is independent of any concrete commercial tool vendor. It is quite scalable, it allows the representation and management of massive as well as small systems’ models. It is a language that was originally conceived and has evolved mainly as a development tool for software applications. UML está basado en un modelo bien definido semánticamente que se denomina “UML Metamodel”. El modelo semántico es a la vez “amplio” (cubre la mayoría de los aspectos necesario para la especificación de sistemas software) y “profundo” (contiene la suficiente información para generar prototipos ejecutables destinados a su validación, o para generar esqueletos de código fuente). Es un lenguaje basado en una notación gráfica fácil de usar y comprender basado en un conjunto reducido de tipos de diagramas (diagramas de clases, diagramas de despliegue, diagramas de estados, diagramas de actividad, diagramas de secuencias y diagramas de casos de uso) estandarizados y que además se basan en un conjunto de principios comunes. Es un lenguaje gestionado en su creación y mantenimiento por el grupo internacional OMG (Object Management Group) que es independiente de cualquier fabricante con interese comercial, lo cual garantiza su permanencia y estabilidad, así como la existencia de múltiples fuentes y diferentes tipos de herramientas. La primera versión UML 1.1 fue propuesta a finales de 1997, y hace unos meses ha aparecido la versión UML 2.0. El curso se basará en la versiones 1.2 y 1.4. que son las soportadas por las herramientas. Es un lenguaje de tercera generación que ha heredado la experiencia de dos generaciones de herramientas previas y de cientos de especialistas que las han utilizado. Actualmente es un lenguaje refinado para que pueda ser eficientemente aplicado en el desarrollo de aplicaciones software, tanto si son proyectos pequeños llevados por una o dos personas o si son grandes proyectos desarrollados por cientos de personas.

7 Basic semantic aspects of a system in UMLFunctional aspects: It describes the functional specification of a system, independently of its implementation. It covers the usage of the system and the ways it is expected to react. Structural aspects: It describes the elements that form the model as well as the parameters that characterize them in a quiantitaive way, and the relationships among them. Behavioral aspects: It describes the inner behavior of the elements, concrete scenarios for their dynamics, and the externally visible interaction between groups of them. La semántica de un sistema se describe a través de tres aspectos complementarios: Los aspectos funcionales del sistema se refieren a la especificación funcional y no funcional (Q&S) del sistema que se desarrolla con independencia de la implementación que se proponga o realice. En UML la descripción funcional se realiza mediante diagramas de casos de uso. Estos diagramas modelan cómo se va a usar el sistema y cómo se espera que el sistema responda. Los elementos estructurales describen las “cosas” que constituyen el modelo, ya sean en fase de diseño como son las clases o tipos como en fase de ejecución como son los objetos o instancias. Así mismo, estos elementos se describen con diferentes niveles de abstracción, tanto a pequeño nivel próximo al código como son las clases, interfaces u objetos, como a gran nivel próximo a la organización arquitectural como son los subsistemas y los componentes. Así mismo, las relaciones entre las clases que describen sus interdependencias son también parte de la estructura del modelo. Los aspectos de comportamiento incluidos en el modelo definen como se comportan o interactúan entre si los diferentes elementos formulados en la estructura. Para los elementos estructurales individuales (clases, objetos, subsistemas, componentes, casos de uso) UML permite describir su comportamientos a través de diagramas de estados o diagramas de actividad que describen la secuencias de estado que siguen en función de las interacciones que reciben, mientras que para las agrupaciones de elementos estructurales, UML permite describir los posibles patrones de interacción a través de diagramas de colaboración o diagrama de secuencias.

8 Static: Organizational/structural modeling resourcesUML diagrams Static: Organizational/structural modeling resources For modeling system’s functionality: Use Case diagrams For modeling system’s architecture: Class diagrams Components diagrams Dynamic: Behavioral modeling resources: For the dynamics of an element: State charts (event driven model) Activity diagrams (operational model/flow charts) For concrete execution scenarios: Sequence diagrams Collaboration diagrams UML ofrece muchos recursos para expresar tanto los elementos estructurales que forman un sistema como su funcionalidad. Estos recursos pueden utilizarse bien para especificar la funcionalidad, o bien para describir detalladamente esa funcionalidad. En el primer caso se puede considerar como una herramienta de ayuda al análisis o diseño, en el segundo caso, puede llegar incluso a constituir un lenguaje de programación, del que se puede generar automáticamente el código. Los elementos de modelado en UML se muestran a través de diagramas. El tipo de diagramas que nos ofrece UML para definir la estructura de un sistema son: Diagramas de clases: Sirve para describir el conjunto de clases, objetos, interfaces, etc que forman el sistema (los elementos estructurales) Diagramas de componentes: Sirve para agrupar elementos de modelado en elementos de mayor nivel de abstracción. Estos diagramas son estáticos, muestra como se organiza el sistema, no como funciona. Para la descripción de la funcionalidad de estos elementos, es decir de su comportamiento dinámico existen dos tipos de diagramas: Aquellos que describen la dinámica completa de un elemento: Diagrama de estado: sirve para describir un elemento estructural a través de una máquina de estados finitos. Diagrama de actividad: es un diagrama de estado con una semántica específica formulado como forma de expresar algoritmos complejos a través de diagramas de flujo. Muestra el flujo de actividad en actividad del sistema. Elementos para la descripción de mecanismos de operación de interacción entre grupos de objetos del sistema: Diagrama de secuencias: Permite representar a través de diagramas de transferencia de mensajes entre objetos organizados en el tiempo cualquier escenario particular de intercolaboración entre ellos. Diagrama de colaboración: Permite representar a través de diagramas gráficos los escenarios de colaboración que se establecen entre grupos de objetos.

9 Views of a UML model. A UML model may target different levels of detail: Architectural models: they express high level qualitative information. Detailed models: they contain information for the validation of certain properties of the system, the code generation or other model transformations. There is not just one graphical view that expresses the whole semantics of the system. The full semantics is stored in the repository. Having multiple views allows the modeler to focus attention on specific aspects with the proper level of detail: Use case view Classes view Deployment view Components view Graphical views are the mean to introduce the model in the repository. The management of a UML model requires a specific tool that keeps the model consistent along the development process. Con UML el diseñador crea un modelo de aplicación que describe de forma completa, consistente y precisa el sistema que se desarrolla. La información contenida en el modelo puede permitir análisis y simulaciones del sistema a través del modelo, o así mismo ser la base para la generación automática de esqueletos o módulos completos de código fuente destinado a la compilación. Cada vista del modelo describe algún aspecto particular de la semántica del sistema que se muestra a efecto de presentar un cierto nivel de abstracción. La semántica reside en la información contenida en la base de datos en que se almacenan los elementos de modelado, y esta no reside en una vista singular en particular. En un modelo UML bien presentado, el conjunto de las vistas describe la semántica de la aplicación. La multiplicidad de las vistas es de gran utilidad ya que permiten enfocar la atención del usuario a aspectos concretos que requieren una atención especial, con una cantidad de detalles adecuados al estudio que se realiza. Para gestionar un modelo UML se requiere una herramienta específica, ya que no solo debe permitir dibujar las vistas, sino mantener la coherencia entre los componente que se incluyen en las diferentes vistas.

10 Basic structural modeling elementsThe basic structure of a system is described using a reduced set of low level modeling elements: Object: it is a run time concept that keeps linked a data structure with the set of operations that act on them. The data stored in the object define its state and are called attributes or properties. The procedures and/or functions that expose the behavior and/or the interaction protocol of the object and act over its data are called methods or operations.. Class: it is a design time concept that describes the common characteristics of all objects of a kind. Objects are individual instances of a class. Interface: it holds the signature of a set of operations, which as a whole defines a service, a protocol, or a behavior disregarding the way them may be implemented. It is meant for reusability of conceptual behaviors. An interface may not have objects, it has to be implemented by a class, which in turn may have objects exposing such functionality. UML es un lenguaje de modelado que se basa en la orientación a objetos, por ello los objetos, las clases y la interfaces son los elementos de modelado estructural básico. Están destinados a representar e incorporar la información que corresponde con los conceptos de bajo nivel que constituyen la aplicación. Un objeto modela una estructura de datos que se instancia durante la fase de ejecución de la aplicación. El objeto modela tanto la información que lleva asociada y que se describe mediante atributos y las operaciones que pueden operar sobre ella y que se describe mediante métodos. Estos métodos son invocados por otros objetos clientes o por otros métodos del mismo objeto. Una clase describe durante la fase de diseño a un conjunto de objetos que instancian las mismas estructuras de datos y admiten los mismos tipos de operaciones. Durante la fase de ejecución pueden instanciarse muchos objetos que correspondan a la misma clase, mientras que un objeto es siempre la instancia de una única clase. Las clases se pueden definir en función de otras clases definidas previamente, bien por especialización, extensión, agregación, asociación, etc. lo que reduce considerablemente la complejidad de la definición del gran número de instancias que requiere una aplicación. Las interfaces permiten nombrar conjuntos de operaciones que representan un servicio completo y que pueden ser ofertados por diferentes clases que los ofertan. Su función es independizar el servicio de la implementación. Dos clases que realicen una misma interface, ofrecen el mismo servicio, lo que significa que si una clase requiere un servicio, lo puede obtener de cualquier clase que realice la misma interfaz. Una interfaz no es directamente instanciables. Las interfaces se realizan a través de clases. Para ello la clase debe implementar un método concreto, por cada operación de la interfaz.

11 Class It models the commonalities of a set of objects that share :The same kinds of properties (Attributes) The same behavioral units (Operations) The same relations with other objects (Associations) A common basic semantics (eventually common Stereotypes) The analysis tries to identify the types of objects (classes) that are key to understand the problem that is to be solved. To identify the relevant classes, the analysis process encompasses: Identify names of objects that appear in the problem description. Simple characteristics may indicate attributes while complex elements may indicate objects of other classes. Classes may be categorized by generalization by defining abstract classes. Classes are described identifying their attributes, the operations they offer to other classes objects, and the behavior they hold. The systems behavior is described by collaborations among classes. Representa un grupo de objetos que tienen similares propiedades (atributos) , comportamiento (operaciones) y formas semejantes de relacionarse con objetos de otras clases (asociaciones) y una semántica común (estereotipo). Se utilizan como mecanismo de describir de forma unificada todos aquellos objetos que aunque tienen diferente entidad corresponden a una misma descripción. Todos los objetos tienen una clase, a veces por ser los únicos elementos de la clase la descripción de ambos se hace conjuntamente y sin marcar la diferencias. En el análisis buscamos el modelado del problema por identificar los objetos que forman parte de él y agruparlos en clases que describen sus características y comportamiento. La clases y objetos están en el enunciado del problema y el análisis trata de descubrirlos, pero también hay una fase de invención ya que tienen que ser abstraídos y dotados de los mecanismos que instrumentan su comportamiento. Las clases y objetos suelen aparecer del análisis de elementos como: Cosas tangibles: Coches, Facturas, etc. Personas: Que realizan o llevan a cabo alguna responsabilidad o role (madre, profesor, etc.) Eventos: Aterrizaje, interrupción, requerimiento,etc. Interacciones: Carga, encuentro, intersección, etc.

12 Graphical representation of a class in UMLName Sensor <> - value: SensorData + calibrationConstant: constant LongInteger= 100 - Acquire(): SensorData + GetValue():Integer + SetCalibrationConstant(newCC:LongInteger) Stereotype Attributes Visibility Operations Parameters Default Values Documentation Documentación SensorData En UML una clase se representa mediante un rectángulo con tres compartimentos, el superior contiene el identificador y en su caso el estereotipo, el medio contiene los atributos, y el inferior, las operaciones o métodos que tienen asociados. El estereotipo que puede ser asociado no solo a las clases, sino a cualquier elemento UML, le asocia una semántica especial. Los atributos se definen mediante un identificador, y en su caso, su tipo un valor por defecto y su visibilidad. El tipo puede corresponder a algún tipo primitivo definido en el dominio o cualquier otra clase definida en el sistema. La visibilidad indica quien puede hacer referencia a ellos (privados (-), públicos (+), reservados (#) o de paquete(~) y es fuertemente dependiente del lenguaje que se utilice. Las operaciones se definen mediante un identificador, un conjunto de parámetros con sus identificadores, tipos y valores por defecto, el tipo del valor de retorno, y la visibilidad. Las clases pueden estar declaradas como abstracta, en cuyo caso no son directamente instanciables, y solo tienen la función de servir como base para la declaración de nuevas clases derivadas de ellas. Las clases pueden ser de instanciadas, lo que representan que los atributos y los procedimientos están definidos en función de la clase y no de sus instancias. Los atributos y las operaciones también pueden declararse como de clase (estáticas), y ser compartidos por todas las instancias. Cualquier elemento de la clase tiene asociada un texto de documentación y a través de ellos se le pueden asociar nuevos parámetros introducidos por el diseñador.

13 Class Diagrams

14 Declaration of InterfacesSensorClient <> PreassureSensor acquire getValue setCalibrationConstant I_Sensor <> <> <> I_Filter LowPassFilter Las interfaces son conjuntos de operaciones agrupadas bajo un identificador por corresponder a un servicio que pueden ser ofrecidos por múltiples clases. En UML se representan como una clase con el estereotipos <>. En un diagrama de clases una interfaz se representa o bien con el símbolo de ordinario de clase o bien mediante un icono consistente en un círculo. Una clase que realiza una interfaz puede representarse bien asociándole el icono de la interfaz, o bien representando la clase como derivada de la clase que representa la interfaz y asignando a la asociación el estereotipo <>. Cuando una clase requiere el servicio representado por la interfaz para implementar su métodos, se relacionan mediante una asociación de dependencia con el estereotipo <>. En fase de ejecución la interfaz deberá ser sustituida por una implementación de una clase que realice esta interfaz. filterValue(value:Integer):Integer -lowPassParam: Integer + filterValue(value:Integer):Integer + init(lp:Integer)

15 High-level structural modeling elementsThese elements describe the system architecture from a high level of abstraction point of view: Package: It is a container, used to manage modeling elements in an organized way. Subsystem: This is a very high-level structural element, used to decompose the whole system into complementary blocks usually with a clearly distinctive functional interaction among them. Component: A set of modeling elements that group them as a replaceable whole. This implies the need to specify its offered as well as its required interfaces. Node: It models a physical computational element on which software elements can be executed. Dada la complejidad de los sistemas que actualmente se desarrolla, es habitual que el sistema deba dividirse en grandes módulos que facilite su gestión. UML ha definido la semántica de ciertos elementos de modelado que facilitan la gestión de estas grandes unidades. Los paquetes son elementos de modelado que tienen como función servir de contenedores de otros elementos de modelado a efectos de su organización. Los paquetes se utilizan para dividir los modelos en fragmentos a fin de que puedan ser gestionados mas eficientemente o procesados por personas o equipos diferentes. Los paquetes solo contienen elementos que existen en a fase de diseño y nunca corresponden a algo que sea instanciable. Sirven para organizar modelos o para proporcionar un dominio de denominación. Los subsistemas son utilizados para organizar módulos de elementos que van a existir en la fase de ejecución del sistema y que se agrupan en función de que colaboran para proporcionar una determinada funcionalidad. Los sistemas son los elementos de mayor nivel de abstracción destinados a describir la arquitectura física de un sistema. Los subsistemas contienen información sobre las operaciones, servicios y especificaciones de QoS e implementación. Los componentes son elementos de organización de módulos de un sistema, semejantes a los subsistemas, pero que por corresponder a servicios completos y bien definidos se caracterizan por constituir unidades reemplazables. Los nudos son elementos de modelado de unidades hardware (procesadores, redes de comunicación, equipos, etc.) que constituyen la plataforma en la que se va a ejecutar el sistema que se desarrolla.

16 <>Example of packages Medical Stuff Temperature Patient Parameter Heart Rate * PVC Count Patient User Interface Stuff <> view Window Control Window En UML los paquetes se representan por un icono en forma de carpeta. En ella se incorporan los elementos de modelado que contienen. Las carpetas como todo elemento UML pueden tener asignado un estereotipo. En el ejemplo la carpeta User Interface Stuff se le asignado el estereotipo <>, lo que significa que utilizamos el paquete como forma de agrupar elementos que corresponden a un mismo dominio del problema. Las carpetas UML tienen la misma semántica que las carpetas de los sistemas de ficheros, y son elementos contenedores que pueden agrupar cualquier tipo de elemento de modelado o de diagrama de visualización. Aunque los paquetes pueden representarse en los diagramas de clases a efectos de organizar los elementos de modelado estructural, su contenido real debe ser observado a través de los navegadores del modelo, que se organizan en función de los paquetes que se definen. Waveform Control Histogram Control Scrollbar Icon Control

17 Subsystems I_Power Power Subsystem Switch Battery Power Source<> I_Power <> Power Subsystem requestPower(amps:Float) Switch < Battery Power Source Solar Panel Voltmeter I_Battery Los subsistemas se representan mediante iconos de clases con el estereotipo <>. Los elementos que incluye un subsistema pueden incorporarse mediante superposición (como en la figura) o a través del campo de atributos y haciendo referencia a clases definidas en el modelo, mediante asociaciones (habitualmente de tipo composición) con otras clases definidas en la vista. La funcionalidad que ofrece el subsistema puede modelarse a través del campo de operaciones que ofrece la clase, o también expresando que el subsistema realiza interfaces que son descritas externamente al subsistema.

18 ECG Acquisition ModuleComponents and nodes Physician ECG Acquisition Module Display Computer TC/IP Stack Patient Data Base GUI Ethernet Data Adquisition Medical Monitoring Patient TC/IP Stack Los componentes se representan en UML a través de clases con el estereotipo <> o a través de un icono específico (ver figura). El nudo se representa mediante un icono de tres dimensiones. En la figura se muestran también actores, que son elementos físicos que interaccionan con el sistema que se desarrolla pero que están fuera del ámbito de diseño. A menudo los componentes, subsistemas y nudos se representan conjuntamente en diagramas de despliegue Math Library

19 Structural elements hierarchy<> <> <> <> <> <> <> <> <> Aunque los conceptos de sistema, subsistema, componentes tienen una semántica bien definida y suele estar claro su uso, en UML no está definida su jerarquía relativa, ni su granularidad. En este curso seguiremos el criterio (no requerido en UML) de que los sistemas se componen de subsistemas (con los niveles de especificación que se necesiten), los subsistemas se componen de componentes (si el concepto de componente se considera necesario) y por último, unos y otros se describen en función de clases, interfaces y objetos. <> <> <>

20 They abstract relationships like:Associations They abstract relationships like: Aggregation: “It is part of…” Simple aggregation : “It is contained in…” Composition: “It is composed of...” Generalization: “It is a kind of...” Inheritance: “It extends...” Specialization: “It specializes...” Dependency Link: Have access to… Abstraction: (<>, <>,...) Bind: (Between generic and concrete classes) Usage: (Make use of..., Have visibility to...) Permission: (<>, <>,...) Clase A Clase B Clase A Clase B Clase A Clase B Clase A Clase B «link» Las asociaciones son los elementos que ofrece UML para representan las relaciones que existen entre los elementos estructurales que se utilizan en los modelos. La asociación es un concepto de la fase de diseño y se establece entre clases, mientras que el enlace (“link”) es su instanciación para los modelos de la fase de ejecución. En UML se definen muchas clases de asociaciones: Asociación : Representa que durante alguna fase de su existencia una clase requiere tener acceso o referencia a otra clase para poder satisfacer su funcionalidad. Agregación: Representa una clase que es parte de otra. Composición: Es un tipo de agregación fuerte que significa que una clase se compone de otras clases definidas. La diferencia entre agregación simple y composición esta en la exclusividad (una clase puede estar agregadas en varias otras clases) y de responsabilidad de creación y destrucción (si una clase está relacionada por composición con otra, ésta es responsable de que aquella se cree y se destruya con su creación y destrucción. Generalización: una clase es una generalización de otra si es un tipo de ella, esto es, donde pueda estar la clase mas abstracta puede estar la clase mas concreta. Existen dos formas básicas de generalización: Herencia: Una clase se crea a partir de otra, incorporando de la antecesora todo lo establecido en la definición de ella mas nuevos aspectos que se añaden en su declaración específica. Especialización: Una clase se crea a partir de otra, especializando su funcionalidad de acuerdo con nuevas necesidades. Clase A Clase B «uses»

21 Examples of associationsLámpara Base Pantalla Fluorescente Incandescencia Conmutador Cables Reactancia Cebador Casquillo Base_bayoneta

22 Associations multiplicityGrade 1 One and only one 0..1 Zero or one 0..n Zero or more 1..n One or more Unspecified Diplome Student Assignment 1..n 0..n Mark Name Title 0..n 1 Do 0..1 1 Room Cada función de una asociaciones lleva una indicación de multiplicidad que muestra cuantos objetos de la clase considerada pueden ser relacionados con un objeto de otra clase. La multiplicidad es una información consecuencia de la función, bajo una expresión entera acotada. Un valor de multiplicidad mayor que 1 implica un conjunto de objetos y debe ser implementado con algún tipo de contenedor (array, lista, cola, etc.) Los valores de multiplicidad implica restricciones relacionadas con el ámbito de la aplicación, válidas durante toda la existencia de los objetos. Las multiplicidades no deben considerarse durante los regímenes transitorios, como en la creación y destrucción de objetos. La materialización de las asociaciones toma todo su interés para las asociaciones n a n. En las asociaciones 1 a 1, los atributos pueden desplazarse a cualquiera de los objetos. En las relaciones 1 a n pueden asociarse a la clase del lado n, sin embargo en la clase n a n el desplazamiento no es posible, y se requiere asociar una clase (contenedora del atributo) a la propia asociación. Number

23 Constraints on associationsPerson 1 Account {Ordered} Class Person {subset} 1..n 0..n student delegate Professor University Person 1..n {exclusive OR} 1..n Student Pueden definirse diferentes tipos de restricciones entre las asociaciones de una clase. Las restriciones se representan en los diagramas por expresiones encerradas entre llaves. La restricción {ordenada} puede colocarse sobre una asociación para especificar una relación de orden entre los objetos enlazados por la asociación. La restricción {subconjunto} indica que el conjunto de una asociación está incluido en el conjunto establecida por la otra asociación. La restricción {O exclusiva}indica que para un objeto dado, es válida una sola asociación entre un grupo de asociaciones. Las asociaciones pueden también enlazar una clase consigo misma. Este tipo se llama asociaciones reflexivas. El role de las asociaciones toma toda su importancia para distinguir las instancias que participan en la asociación. Person Parent 1..2 Son 0..n

24 Examples of associations in a class diagramPatient Heart Rate Heart Rate Display CommunicatingObject CommSubsystem <> Communicator MsgQueue Message CacheQueue CANBus Ethernet Interface Semaphore <> Send(m:message) Receive():Message - head: Integer - tail:Integer - size: Integer Insert(m: Message) Remove(m: Message) GetSize(): Integer Init() IsEmpty():Boolean - theFile: File Save() Load() 1 0..n recipient outputQueue inputQueue theTransQueue theRecQueue Dependencia: Es un tipo de asociación muy débil en la que se indica que para definir o explicar una clase se debe tener en cuenta la definición de la otra. Ejemplos de dependencias son: <> una clase resulta como una concreción de otra mas abstracta; <> una clase resulta de concretar una clase genérica; <> una clase hace uso internamente de otra, y en consecuencia, requiere visibilidad sobre ella. <> una clase tiene derechos especiales de acceso a los recursos de otra. Una asociación se representa en los diagramas de clases UML como una línea que enlaza las clases que se realciona. La agregación se representa mediante un pequeño rombo en el extremo próximo a la clase contenedora. Si la agregación es simple, el rombo está vacío, y si es una composición el rombo esta relleno. La herencia se representa mediante un pequeño triángulo vacío en el extremo de la clase mas general. La dependencia se representa mediante una línea punteada. Las asociaciones pueden estar orientadas o no. Una asociación orientada se expresa con una flecha y es solo utilizada por la clase origen para hacer uso de la clase destino. Si no no es orientada se representa sin flecha, y en ese caso es utilizable por ambas clases. En los extremos de una asociación se puede incluir la cardinalidad, esto es el número de objetos de esa clase con los que se puede estar enlazado en fase de ejecución. En los extremos de una asociación se pueden incluir un identificador o “role”.

25 Modeling the behavior The resources offered by UML to describe the dinamic behavior of structural elements like objects, classes, systems, subsystems and components at run time are presented in: State charts: They are used to describe the internal evolution of a class or method due to the occurrence of external o internal events. It exposes the states in which the element can be and the events that trigger transitions between them.. Activity diagrams: Represent the flow of execution of a method. Sequence diagrams: They show concrete interactions between objects formulated as sequences of events or messages organized in time. Collaboration diagrams: They work as sequence diagrams but highlight the concrete elements that participate and their links instead of the evolution of the interactions in time. UML ofrece muchos recursos para expresar la funcionalidad de los elementos estructurales. Estos recursos pueden utilizarse bien para especificar la funcionalidad, o bien para describir detalladamente esa funcionalidad. En el primer caso se puede considerar como una herramienta de ayuda al análisis o diseño, en el segundo caso, puede llegar incluso a constituir un lenguaje de programación, del que se puede generar automáticamente el código. Elementos para la descripción de elementos estructurales y su funcionalidad: Diagrama de estado: sirve para describir un elemento estructural a través de una máquina de estados finitos. Diagrama de actividad: es un diagrama de estado con una semántica específica formulado como forma de expresar algoritmos complejos a través de diagramas de flujo. Elementos para la descripción de mecanismos de operación de interacción entre grupos de objetos del sistema: Diagrama de secuencias: Permite representar a través de diagramas de transferencia de mensajes entre objetos organizados en el tiempo cualquier escenario de intercolaboración entre ellos. Diagrama de colaboración: Permite representar a través de diagramas gráficos los escenarios de colaboración que se establecen entre grupos de objetos.

26 Actions and ActivitiesAction: It abstracts an executable primitive that is able to cause a change in the system state: generation of an event, change in the value of an attribute or link, etc. It models a simple statement with the “run to completion” semantics (It runs disregarding others until it finishes) Some kinds of actions: CreateAction (constructor) or Destroy Action (deletion of an object). CallAction (synchronous invocation of an operation). ReturnAction (return of control from an operation) or TerminateAction (return of control signaling the end of a sequence of actions) SendAction (asynchronous transference of an event) ActionSequence) (an action composed by a sequence of them) Activity: It is a sequence of actions that execute in the context of a particular state of an object. It finishes when the object changes its state, which may occur due to the arrival of an external or timed event, or because the sequence finishes. It does not imply the assumption of a “run to completion” semantics Una acción es una especificación de una primitiva ejecutable que tiene como consecuencia un cambio de estado en el modelo, y puede consistir en la transferencia de un mensaje, modificar un enlace o cambiar de valor un atributo. Las acciones son primitivas computacionales simples que tienen la semántica de iniciarse para ser terminada (“run-to-completion”). Esto no significa que no pueda ser expulsada de su ejecución por otra de mayor prioridad, sino que aun en este caso posterior se retorna a ella para completarla. Un objeto que este ejecutando una acción, no acepta nuevos mensajes hasta que la concluya. Clases de acciones que especifica UML 1.4 son: “CreateAction”, “CallAction”, “ReturnAction”, “SendAction”, “TerminateAction”, “DestroyAction”, “ActionSequence” y “UninterpretedAction” Una actividad es una primitiva ejecutable que se ejecuta mientras que el elemento se encuentra en un determinado estado y que termina cuando finaliza o cuando el elemento cambia de estado. Una actividad no tiene la semántica “run-to-completion” y si un objeto está ejecutando una actividad y recibe un mensaje, puede concluirla y cambiar de estado.

27 State charts They are used to describe the behavior of structural elements or methods in a finite state machine. This implies to represent the possible states of the element and the potential transitions among them. The actual behavior is specified by actions linked to: Transitions between states The “entry” to each state The “exit” of each state The staying in a state may have an activity associated. UML State charts have significant expressive power and scalability: A state may have an aggregated state chart. They can express concurrency by introducing AND states. Dynamic semantics is supported by using pseudo-states. Transitions may be guarded and synchronized. Un diagrama de estados describe una máquina de estados finita basada en un conjunto de estados en que se puede encontrar el sistema, el conjunto de transiciones entre estados disparados por eventos, y los conjuntos de acciones o actividades que se ejecutan en función de las transiciones que se realizan o de los estados en que se encuentra el sistema. Los diagramas de estado UML admiten: Estados formulados como diagramas de estados. Máquinas de estados concurrentes sobre un mismo diagrama, y por tanto la definición de estados compuestos AND del elemento. Diferentes tipos de psudoestados para organizar la inicialización, acceso, salida o persistencia en las máquinas de estado. Admite transiciones condicionales en las que en función de condiciones de guarda las posibles transiciones se habilitan o deshabilitan. Admite pseudoestados destinados a la sincronización de eventos concurrente o a la generación simultánea de multiples eventos. Permite utilizar eventos asíncronos que son implementados a través colas de eventos en el destino, esto es, eventos que el que los genera los olvida, pero que se mantienen encolados en el destinatario está que está en un estado en el que puede gestionarlo. También admite eventos síncronos en el que se sigue la política de que el que los envía permanece bloqueado hasta que el evento es gestionado.

28 Example: Garage door Opening Closed Closing Open External events:- PushBotton - FullyOpen - FullyClosed - ObstacleFound Closed do/ MotorStop Opening entry/ StartUp exit/ Stop do/ MotorUp Closing entry/ StartDown do/ MotorDown Open PushBotton FullyOpen FullyClosed ObstacleFound TimeOff( 30 s ) Actions: - StartUp - StartDown - Stop Activities: - MotorUP - MotorDown - MotorStop

29 State chart notation operating processing Working Filtering AcquiringevDataReady entry/enableSensor(); do/D=GetData(); exit/disableSensor(); entry/d=filterData(); do/x=Xdata(d); do/y=Ydata(d); evAbort Idle [dataBad] Verifying Controlling [dataOk] entry/enableMotor(); do/SetAxis=(x,y); do/DisableMotor(); entry/CheckData(); do/CheckPosition(); testing evOK Handling Checking tm(CheckTime) evError Waiting entry/LogError(); do/if HANDABLE then GEN(evOK) else GEN(evBAD) Un diagrama de estado es representado mediante óvalos que representan los estados y aristas que representan las transiciones. A un estado se puede asociar las acciones que se ejecutan cuando se accede a él (entry/) o se sale de él (exit/) y la secuencia de actividades que se ejecutan mientras se está en él (do/) A una transición se le pueden asociar condiciones de guarda ([ ]) que habilitan/deshabilitan su tránsito. Así mismo, a una transición se pueden asociar las acciones que se ejecutan cuando se transita por ella. Dentro de un estado se pueden incluir una sección de diagrama estados, que indican subestados discernibles dentro de él. Mediante líneas discontinuas se separan diferentes máquinas de estados finitos que concurren dentro de un mismo diagrama. Existen definidos muchos pseudoestados para organizar el diagrama: Estado inicial: (circulo relleno) Punto de inicio de la actividad en el diagrama. Estado salida: (ojo de buey) Punto por el que se abandona la actividad. Condicional: (rombo) Se elige una transición de acuerdo con una condición. Historico:(Circulo con H) Se inicia la actividad por el estado en que se abandonó. do/ if FAILED then GEN(CheckData(); UnrecoverableError evBad/GEN(evAbort)

30 Activity diagram It might by considered as a special case of a state machine used to describe the flow of control inherent to the execution of an operation. It models sequential as well as concurrent flows of control. The transition between two consecutive states is triggered by the end of the activity associate to the previous state. They are used to describe the internals of the algorithms.

31 Elements of the activity diagrams.Event_1 Decision Wait event Activity_C Activity_A [T>20º] [T<=20º] Activity_A finished Activity_D Activity_E State Activity_B Actividad: Tarea que es realizada dentro de procedimiento o caso de uso que se describe. Estado: Etiqueta que hace referencia a un estado de ejecución del proceso descrito por el diagrama. Espera de evento: El flujo de control se suspende hasta que se genera un evento o mensaje. Emisión de un evento: Se genera un evento o mensaje que puede ser un resultado o una forma de interacción con otras secciones de la tarea. Bifurcación condicionada (Branching): El flujo de control pasa a una u otra rama del diagrama, en función de que satisfaga o no una cierta condición. Convergencia (Merge): Varia líneas alternativas se encauzan hacia una secuencia de actividades. Activity_F Event_2 Raise event

32 A usual representation for concurrency.Activity_A Swimlane Generation of concurrent flows (fork) Thread_3 Thread_1 Thread_2 Activity_D Activity_B Activity_C Activity_E Convergence of concurrent flows (joint) Los diagramas de actividad permiten formular ejecuciones concurrentes de actividades. Barras de generación de concurrencia (Fork): El flujo de control se replica en varias líneas que se ejecutan concurrentemente. Barras de sincronización (Joint): Las diferentes líneas de control de entrada se suspenden en ella hasta que todas la ha alcanzado. Luego se unifican en una única linea de control. Pasillos de actividad (Swimlane): Representan a los objetos o procesos que soportan las diferentes líneas de flujo de control concurrentes. Activity_F

33 Additional example of activity diagram.GraspAt(x,y,z) Proximity Sensor evIsNear Alarm System [area not clear] AnnunciateAlarm [area clear] ComputeJointAngles(a,b) Joint 1 to a Joint 2 to b OpenGrip RotateGrip Grasp Object

34 There are two behaviorally equivalent presentations:Interaction diagrams They serve to model the collaborative behavior of groups of structural elements. They are formulated as partial/typical/expected scenarios with the exchange of messages that express the interaction between objects. The messages are in practice events, the invocation of operations, or the creation/destruction of objects. There are two behaviorally equivalent presentations: Collaboration diagrams: These show concrete objects and links, and add to them the messages that they interchange ordered by means of a numbering notation. Sequence diagrams: These diagrams present the interacting objects, and show the messages they exchange as arrows ordered graphically in a top-down way, indicating the partial order between them.

35 Sequence charts This is used to express graphically time ordered interactions between objects. Such interactions occur between them as an expression of their collaborate behavior to accomplish the responsibilities of the whole Only one of the possible execution scenarios is shown. This corresponds to a particular execution of a function or use case of the system It is the basic mechanism used by a non-expert to describe interactions A sufficiently large set of sequence charts may actually bring the description of the whole system behavior, but this is tedious and significantly error prone. Other behavioral diagrams are used for such specification purposes instead. Los diagramas de secuencias son representaciones gráficas del flujo de control y son útiles en particular para visualizar las ejecución de los casos de uso. Además de utilizarlo como una herramienta en el análisis de requisitos también es muy útil como herramienta de análisis, como se verá en el próximo tema. Los diagramas de secuencias requiere que se piense en términos de objetos. En un diagrama de secuencia, la vida de cada objeto se muestra como una línea continua vertical con el nombre del objeto y su clase en la parte superior. Cada interacción entre objetos se muestra como una flecha horizontal desde el objeto que la inicia hasta el objeto que la recibe. El orden de envío de los mensajes viene dado por la posición sobre el eje vertical.

36 Example: A phone call Caller Phone Network Callee TimeCaller lifts receiver Dial tone begins Dial Dial tone ends Dial… Ringing tone Phone rings Answer phone En la figura se muestra un ejemplo de diagrama de secuencias que describe el proceso de comunicación de dos personas (Llamador y llamado) a través de una línea telefónica. La interacción entre objetos se conciben como mensajes que se intercambian entre objetos. El diagrama de secuencias no describe la totalidad de las posibilidades que se pueden plantear, sino que únicamente describe una secuencia posible. Por ejemplo, en este caso no se contempla la posibilidad de que el objeto Llamado esté comunicando, y en consecuencia falle la conexión. Esta situación diferente debería formularse con otro diagrama de secuencia. Tone stops Ringing stops Hello?

37 Interactions are between objectsDifferent object may play The same role Class or role Object Anonymous object Juan: Caller :Phone-System Pepe: Caller Los participantes en un diagrama de secuencias son objetos concretos. Su denominación consta del identificador del objeto y de la clase o papel al que pertenecen. Puede designarse un objeto como representativo de una clase haciendo únicamente referencia a la clases.

38 Timing marks Object_1 Object_2 Object_3 Object_4 A.send=>A.Receive¿¿A.send=>B.Send?? A.Receive=>C.Send C A.Reseive=>D.Send E D Partition line ¿¿B.Send=>E.Send?? D.Received=>F.Send F G H G.Send=>I.Send Aunque la dirección vertical representa la evolución del tiempo, solo son comparables los instantes de las acciones si están referenciadas a la actividad de un mismo objeto. La acción de enviar un evento es siempre anterior a su recepción. Así, A.Send =>A.Receive (la acción A.Send precede a la acción A.Receive) Para dos acciones que no tengan referencia con un objeto común no son ordenables: A.Send puede preceder o seguir a B.Send. Cuando existe una secuencia de referencias comunes, puede establecerse la precedencia. G.Send=>G.Receive=>H.Send=>H.Receive=>I.Send=>I.Receive A través de una línea de partición horizontal, se pueden establecer precedencias explícitas: E.Send=>E.Receive=>G.Send=>G.Receive J I ¿¿G.Receive>=J.Send??

39 Synchronization of messagesObject_A Object_B Object_C Object creation Asynchronous message Asynchronous message* Object_D Conditional message* Wait* Message with timeout* Synchronous message Self message Explicit return Mensaje Síncrono: El flujo en el objeto que envía el mensaje se suspende hasta que es recibido por el objeto receptor. Mensaje Asíncrono: El emisor transfiere el mensaje y continua sin esperar a que el mensaje sea recibido. Mensaje Condicionado(Balking): El mensaje es transferido si el receptor está disponible para aceptarlo de forma inmediata, en caso contrario, no se transfiere. Mensaje Temporizado: El mensaje es transferido con un tiempo de guarda. Si transcurre el tiempo de timeout y el receptos lo lo acepta, el mensaje no se emite. Espera: Un objeto se suspende hasta que otro objeto alcanza un cierto estado. Return: Habitualmente el retorno de una invocación es implícita. Algunas veces interesa manifestar su ocurrencia. Los patrones de generación de los mensajes pueden explicitarse mediante iconos. Todos estos iconos están definidos en el estándar UML, pero no suelen estar soportados por las herramientas CASE. Por ello, se suele utilizar el método equivalente de la inclusión del estereotipo explícito. Stereotyped message <> Object deletion * Notation deprecated in UML 2

40 Additional syntax in sequence chartsObject_1 Object_2 [Condition] Message_1 if Condition then message_1 else message_2 [not Condition] Message_2 [X] Message_1 case Variable of X=> message_1 Y=> message_2 [Y] Message_2 En los diagramas de secuencias pueden establecerse precondiciones para la realización de una interacción. La precondición se formula entre paréntesis cuadrados. El mensaje se transfiere solo si la condición es cierta. Haciendo uso de interacciones condicionadas, pueden describirse bifurcaciones condicionales, bifurcaciones enumeradas y bucles enumerados o condicionales *[X] Message While X do Message

41 Timing Constraints Object_A Object_B Object_C a {PERIOD(a)=10 s} e{AVERAGE(b-a)=5 s} f {f-e<=1s} b a’ Los instantes en que se producen las acciones se pueden designar mediante etiquetas. Y haciendo uso de ellas se pueden formular múltiples restricciones sobre las respuestas temporales de los sistemas. b’

42 Collaborations (UML1.x)They model interactions between objects that collaborate to implement a given functionality or use case. They refer mainly to the links between objects. They are specially useful to describe protocols. They describe concrete scenarios for particular situations, not general behaviors. The expressive power is similar to sequence charts. The emphasis here is in the communication links, while in the other is on the order of occurrence. Los diagramas de colaboración muestran interacciones entre objetos, resaltando la estructura espacial estática que permite la colaboración del grupo de objetos. Los diagramas de colaboración expresan a la vez el contexto de un grupo de objetos (a través de de la representación de los objetos y de los enlaces que están establecidos entre ellos) y las interacciones entre los objetos (por la representación de envío de mensajes). El contexto de una interacción puede comprender los argumentos, las variables locales creadas durante la ejecución, así como los enlaces entre los objetos que participan en la interacción. Una interacción se realiza mediante un grupo de objetos que colaboran intercambiando mensajes. Los mensajes se representan a los largo de los enlaces que enlazan los objetos por medio de flechas orientadas hacia el destinario del mensaje.

43 A collaboration diagram example.9. Display Message “That selection is empty” CokeRack:Rack :MessagerDisplay :Can 7. Release 8. Light on ButtonPanel 6. Push CokeButton:Button CokeLed:Led 10. Push FantaButton:Button 11. Release 5. Enable Buttons 12. Disable button FantaRack:Rack 13. Reset Coin :Can Escenario ejemplo: Drink Machine: El usuario introduce 60 céntimos como dos monedas de 50 céntimos y una moneda de 20 céntimos, y la máquina retorna una moneda de 10 céntimos. Selecciona Coke, pero la máquina no tiene este tipo de bebida y lo manifiesta a través de un LED y un mensaje. Luego elige Fanta que si está disponible, por lo que la máquina la suministra. 1. Insert 50 c. 2. Insert 50 c. 3. Insert 20 c. :CoinReceptacle 4. Return 10 c. FantaLed:Led User

44 The order is expressed explicitly as an indexSystem Sensors & actuators Interface Door Elevator Floor Control LAN RS-232 Passenger Potential passenger Technical service Elevator System Status 1a: Call 2a: Status 3a: Arrive 4a: Enter 1b: Select floor 2b: Other commands 3b: Status 4b: Leave Alarm Call Event The status is observed The call button is pushed The elevator goes to that floor En los diagramas de colaboración el tiempo (orden en el tiempo) se puede expresar introduciendo un índice en los mensajes. En sistemas concurrentes en los que existen diferentes sesiones de interacción se utiliza un segundo índice de sesión.

45 A sequence chart example:Coin Receptacle :Button Panel CokeButton: Button CokeRack: Rack CokeLed: Led :Message Display FantaButton: Button FantaRack: Rack User Insert 50 c. Insert 50 c. Insert 20 c. Return 10 c. Enable button Push Release Light On Display Message Push Escenario ejemplo: Drink Machine: El usuario introduce 60 céntimos como dos monedas de 50 céntimos y una moneda de 20 céntimos, y la máquina retorna una moneda de 10 céntimos. Selecciona Coke, pero la máquina no tiene este tipo de bebida y lo manifiesta a través de un LED y un mensaje. Luego elige Fanta que si está disponible, por lo que la máquina la suministra. Release Disable buttons Reset

46 Use case diagrams A use case describes an interaction between the system and an external agent called actor: A use case capture a functionality that is visible for the user (actor). A use case represent a concrete objective of the system for a user. A use case may correspond to a very simple as well as to a quite complex function. In the later case it may be formulated in terms or simpler use cases. Use case diagrams are used in UML to: Delimit parts that belong to the system from those that are external to it. Capture the functional elements of the system. Identify and classify external elements with which the system interacts. Formulate the protocols fo rthe interactions between the system and the actors.. Use case diagrams encompass the system’s functionality, not its implementation. Use case diagrams are an alternative to the context diagram and complement it to formulate the system’s requirements. The functionality of the system expressed in the use cases is used as a guide along the rest of the phases in the development process (analysis, design, coding, tests, and deployment). Los diagramas de casos de uso tienen son un método alternativo y complementario a los diagramas de contexto como medio de especificar los requisitos de una aplicación software. Jacobson creó la idea de los casos de uso al observar que, a pesar del gran número de ejecuciones potenciales, muchas aplicaciones están concebidas en términos de un número relativamente pequeño de interacciones típicas. Muestran los tipos básicos de interacción entre el sistema y los elementos del entorno que operan con él. Los diagramas de casos de uso proporcionan un recurso alternativo bien para verificar el diagrama de contexto o de ayuda para construirlo. Los casos de uso capturan una vista general de la funcionalidad del sistema con un método muy adecuado para ser interpretado por personas no técnicas como son los usuarios y los expertos de dominio. Suelen interpretarse como una guía de los escenarios de uso del sistema sobre los que se especifican los requerimiento del sistema. Los casos de uso son también un método de descomposición de la funcionalidad del sistema en elemento de funcionalidad más básica, ya que UML proporcionan una semántica para expresar los casos de usos mas generales en función de casos de usos mas simples. Los casos de uso son contenedores de la información que describen los requerimientos del sistema. Estos se pueden formular con diferentes niveles de detalles, mas cualitativos para el uso de los expertos de dominio y mas detallado y formales para el uso de los analistas de la aplicación. La mayoría de los estándares de documentación establecidos (incluida IEEE )son anteriores a la definición del caso de uso y en consecuencia no los tienen en cuenta. Es habitual tener que extender su formulación para que tengan cabida.

47 Use cases: Modeling requirementsA use case describes a concrete capacity or functionality required for the system that is offered to a concrete actor . It specifies a function of the system as a whole, disregarding its internal parts or the concrete mechanisms used to deliver it. It acts as a container for the diagrams or texts that are needed to describe its functionality and the quality of service required from the system. Among use cases can be established relations like: Generalization. Inclusion. Extension.

48 Elements in UML use case diagramsActor_1 Actor_2 Actor_3 Actor_4 <> <> <> Use Case 1 Use Case 2 Use Case 3 Use Case 4 Use Case 5 System <> <> El modelo de casos de uso de una aplicación se compone de actores, el sistema (como una caja negra) y los propios casos de uso. La funcionalidad de un sistema se formula examinando las necesidades funcionales que requiere del sistema de cada actor, expresadas en forma de familias de interacciones que se incluyen en un caso de uso. Un actor representa un papel interpretado por una persona u otro sistema que interacciona con el sistema que se describe. La misma persona física puede representar diferentes papeles y asi mismos, muchas personas pueden ser representados por un mismo actor. Los actores deben ser descritos de una forma clara mediante un texto de sólo algunas líneas. Los casos de uso se determinan observando y precisando, actor por actor , las secuencias de interacción (que llamaremos escenarios) que llevan a cabo con el sistema. Los casos de uso agrupan a familias de escenarios que desempeñan un mismo papel funcional visto desde el usuario. Los casos de uso son abstracciones del diálogo entre los actores y el sistema: describen interacciones potenciales, sin entrar en los detalles de cada usuario. Los escenarios son instancias de los caos de uso. Los escenarios representan secuencias de mensajes entre objetos que colaboran para producir algún tipo de comportamiento del sistema. Los escenarios constituyen un método muy intuitivo de representar los detalles de los requerimiento, en particular los que implican restricciones temporales. Los enlaces entre actores y casos de uso representan los protocolos, que constituyen el hilo de conductor de la secuencia de eventos que intercambian ambos.

49 Main actors: Users utilizing the system functions. It represents an entity that is external to the system but interacts with it. Actors may be: Main actors: Users utilizing the system functions. Secondary actors: Users that make administrative or maintenance system tasks. External elements: Equipment or devices that are related to or located in the environment of the application but are not developed with it. Other systems: Systems external to the one under development that interact with it. An object may implement several actors, and an actor may have several implementations. Los actores son cualquier cosa que interacciona con el sistema que se desarrolla, por ejemplo, personas, otro software, hardware, dispositivos, redes, almacenes de datos, etc.. Cada actor define un particular “role”. Cada entidad externa al sistema puede ser representado por uno o mas actores. Así, una persona física puede ser representada por varios actores , debido a que la persona juega diferentes papeles con relación al sistema. O varios objetos físicos pueden estar representados por un mismo actor, porque ellos mantienen una misma interacción en relación con el sistema. Existen cuatro grandes tipos de actores: Los actores principales: Agrupan a alas personas que utilizan las funciones principales del sistema. En el caso del software de un cajero son los clientes que hacen uso de él. Los actores secundarios: Son las personas que hacen tareas administrativas o de mantenimiento. En el ejemplo de un cajero es p.e. la persona que recarga el cajero. Los Elementos externos: Agrupa a los dispositivos que forman parte del ámbito de la aplicación y que deben ser utilizado. En el ejemplo del cajero pueden ser p.e. la impresora. Otros sistemas: Agrupa a los sistemas externos con lo que el sistema debe interactuar. En el ejemplo del cajero, un actor de este tipo puede ser el sistema del sistema bancario. Los actores son siempre externos al sistema. Para tratar de localizar los actores, debemos buscar categorías de cosas que aparezcan como consecuencia de las siguientes preguntas: ¿Quien usa el sistema? ¿Quién instala, arranca y apaga el sistema? ¿Quien mantiene al sistema? ¿Que otros sistemas usa el sistema? ¿Quién obtiene información del sistema? ¿Quién provee información al sistema? ¿Ocurre algo de forma automática en tiempos prefijados?.

50 Use Case diagram for an e-commerce web serviceClient Agent Employee Treasurer Inventory Return product Cancel order Get catalog Order status Order Deliver package Product Information Update stock Refill products Charge payment Enter discount Print label Calculate order cost claim Courier Casos de uso Realiza pedido: Un cliente crea un pedido, selecciona los productos y ordena el pago Estatus pedido: Un cliente requiere información del estado de su pedido. Obtén catálogo: Un cliente requiere el catálogo de productos. Cancela pedido:Un cliente da de baja un pedido ya registrado. Devuelve producto: Un cliente devuelve un producto por fallo. Registra reclamación: Un cliente envía un mensaje de reclamación a la empresa. Envía paquete: Se ordena al sistema de mensajería que se envíe un paquete. Información del producto: Informa el estado de un producto en el inventario. Actualiza inventario: Se analiza el inventario y se realiza los pedidos a los suministradores. Registra producto: Da de alta en el inventario un producto recibido de los suministradores. Carga pago: Anota el pago relativo a un pedido. Registra descuento: Anota en la cuenta de un cliente un descuento recibido. Imprime etiqueta: Imprime la etiqueta de envío de un pedido. Calcula costo envío: Calcula el gasto de envío de un pedido.

51 Packages to organize use casesEnter orders Execute orders Client Agent Return product Cancel order Get catalog Order status Order Enter claim Si el diagrama de casos de uso que resulta es demasiado grande y enmarañado, se pueden crear diferentes diagramas de casos de uso y cada uno de ellos representaría una vista del diagrama general. Cada diagrama puede representar un área de principal de funcionalidad del sistema. O la funcionalidad relativa a un actor, etc. Incluso puede ser conveniente que un mismo caso de uso a parezca en diferentes diagramas. En estos casos la utilización de una herramienta CASE es imprescindible para mantener la coherencia del modelo. En sistema grandes puede ser útil organizar los diagramas en paquetes, cada uno de ellos representa la funcionalidad de un área o de un subsistema.

52 Timed interactions/activitiesSome activities must occur at predefined time instants and are triggered by the internal clock. These kinds of activities may be seen in two ways: Time may be considered as an actor that launches the use case. The pass of time is part of the system and the associated actor reacts motivated by it. Only the first situation can be modeled with use cases since it preserves the principle that a use case is triggered by the will of an actor. Send catalog Start of the quarter Client Time as an actor Time as a part of the system

53 Information that describes the use case.A use case identifies a concrete functionality and relates it to the actor/s that trigger it. It must be documented in such a way that its functionality gets fully formalized for the necessary stakeholders. In the regular practice there are several textual and graphical styles accepted to document use cases. The necessary information for a use case includes: An identifier Actor or actors that can trigger it. Pre- and post- conditions that are applicable. Its basic functionality (text or graph). Alternative paths for its execution, and errors or exceptions that it may rise. Durante la fase de inicio del proyecto hay que decidir lo que hace el sistema que se desarrolla, y debe identificarse la funcionalidad desde un punto de vista conceptual y abstracto. Durante la posterior fase de elaboración hay que detallar los requerimientos del sistema hasta que este quede no ambiguo y pueda ser desarrollado por los diseñadores y programadores. Cada caso de uso incluye todos los detalles sobre lo que tiene que hacerse para conseguir la funcionalidad. Se necesita considerar la funcionalidad básica, las alternativas a ella, el funcionalidad que se produce cuando se presentan errores o estados de excepción, las precondiciones o estado de partida previsto para el caso de uso y las post-condiciones o situación que tiene que producirse cuando el caso de error concluya. Los casos de uso puede incluir pueden incluir condiciones, bifurcaciones, alternativas y bucles de flujo de control. Cuando el caso de uso es sencillo, es fácil describir linealmente la información asociada, sin embargo cuando el caso de uso se hace complejo y presenta muchas ramas o bucles, existen diferentes estilos de describir los casos de uso. La descripción de un caso de uso comprende los siguientes elementos: Inicio del caso de uso:Identifica el evento o interacción que desencadena el caso de uso. Final del caso de uso: El evento o situación con la que el caso de uso concluye. La interacción entre sistema y los actores: describe la secuencia abierta de interacciones que constituye el caso de uso. El intercambio de información: Describe las informaciones o datos que se intercambian en las interacciones. La cronología y el origen de las informaciones: Informaciones que se requieren (internas o externas) Las repeticiones de las iteraciones: Bucles de iteraciones que se realizan dentro del caso de uso. Las opcionalidades de las iteraciones:Bifurcaciones o ramificaciones de interacciones.

54 The use case “Order” as an exampleIdentifier: Order Actors that trigger it: Client and Agent. Pre-conditions: A registered client has successfully logged-in into the system. Sequential flow of events: 1. The client enters name and address. 2. Once the client inserts the zip code the system retrieves the county, town, and state. 3. The client type the codes of the products that form the order. 4. The system reacts by providing the description and price of each product. 5. The system stores temporarily the list of products included in the order. 6. The client enters the payment card data. 7. The client click on the control button labeled as “Send Order”. 8. The system verifies that all required data is provided, store the order in a temporary location and request confirmation of the payment to the bank. If the information provided is not correct the system request corrections to the client. 9. When the payment is complete, the order is accepted, it gets an identification (ID) number, an this ID is returned to the client. Post-conditions: If the order is not canceled it ends being recorded in the system and its ID confirmed to the client.

55 Relationships between use casesThe analysis of requirements gets simplified when some use cases can be formulated as a function of others previously defined. There are three kinds of relationships between use cases: Inclusion <> o <>: This implies a simple functional dependency. Occurs when a use case includes the content (semantics and implementation) of another one by “calling” it in the description of its own flow. This helps to avoid repeating functional segments that appear in multiples contexts. Extension <>: The extended use case is used as a basis to derive others by extension of its predefined extension points. Then creating new functionality. Inheritance: When a use case is more general than other and the derivate one inherits the features from the parent specializing or overwriting some of its functionality UML define tres tipos de relaciones entre casos de uso: Inclusión: La relación inclusión utiliza un estereotipo de dependencia.Establece que un segmento de comportamiento que esta representado por el caso de uso base es utilizado por otro caso de uso que llamamos caso de uso cliente. Esta relación es especialmente útil si existe un segmento de funcionalidad que se repite en diferentes contextos y no se desea repetir su especificación. Extensión: La relación de extensión es representada por una relación de dependencia entre los dos casos de uso, con la flecha apuntando hacia la clase base. El caso de uso a ser extendido es denominado caso de uso base, y el caso de uso extendido es llamado caso de uso cliente. La idea es que el caso de uso base identifica un número de puntos de extensión específicos en descripción de comportamiento. Estos puntos son localizaciones a partir de los que los clientes pueden insertar un comportamiento adicional. Generalización: Esta relación declara que un caso de uso (llamado general) es una forma mas general que otro (llamado derivado). Al igual que en la generalización de las clases, la clase mas especializada hereda de la base todas sus características, de las cuales algunas pueden ser sobrescritas y especializadas por la derivada.

56 Example of an inclusion relationshipClient Cancel order Search order <>

57 An extension relationship example.Order Extension Points <> (Special client) [client in the list of special clients] Sales: before step 5 Special client: before step 5 Discount for preferential clients 1 Start in the point called “Sales” 2 The system makes a discount on the order 3 Calculates the products discount 4 Subtracts the discount from the total <> (Sales) [product in the list of season sales] 1 Start in the point called “Special Client” 2 The system shows “discount” on the order 3 It calculates the discount on the total of the order 4 Subtract the discount from the total Extensión de caso de uso: “Rebajas estacionales” Secuencia básica: 1. El caso de uso comienza en el paso de nominado “Rebajas”. 2. El sistema muestra el descuento sobre el pedido. 3. El sistema calcula el descuento sobre el producto. 4. El sistema substrae la cantidad de descuento sobre la suma total del pedido. Extensión de caso de uso: “Descuento de cliente preferente” 1. El caso de uso comienza en el paso de nominado “Cliente especial”. 3. El sistema calcula el descuento total sobre el pedido del cliente. Season sales

58 Example of inheritance between use casesWEB -Order Order Phone order Client Order status Selling report Agent