modélisation par uml 1 denis laurendeau, p.h.d., ing. département de génie électrique et de...

Modélisation par UML

1

Denis Laurendeau, P.h.D., ing.

Département de génie électrique et de génie informatique

Modélisation en langage UML


2

UML: UUnified MModeling LLanguage

• Travail initié par G. BoochBooch et J. RumbaughRumbaugh en 1994• Objectif: unifier les méthodes de modélisation de:

– Booch

– OMT de Rumbaugh

– OOSE de JacobsonJacobson

• Version 1.0 de UML apparaît en Janvier 1997• L ’OMG’OMG a adopté UML comme langage de

modélisation


3

Objectifs de UML

• Modélisation de systèmessystèmes divers en utilisant des concepts orientés objetsconcepts orientés objets

• Établir un couplage entre les conceptsconcepts et leur implantationimplantation

• Aborder la description des problèmes d ’échelleéchelle propres aux systèmes complexescomplexes

• Offrir une approche de description utilisable par les humainshumains et les machinesmachines


4

Usages de UML

• Systèmes d ’informationSystèmes d ’information pour la présentation d ’informations diverses à des usagers

• Systèmes techniquesSystèmes techniques pour la commande d ’équipements

• Systèmes temps-réelSystèmes temps-réel embarqués

• Systèmes répartisSystèmes répartis sur des réseaux (locaux ou non)

• Systèmes logicielsSystèmes logiciels (exploitation, bases de données, interfaces GUI,etc.)

• Systèmes commerciauxSystèmes commerciaux (description de la structure et du fonctionnement des entreprises: règles, stratégies, politiques, etc)


5

Étapes de développement d ’un système• Analyse des besoinsbesoins: recherche des points points

fonctionnelsfonctionnels (Use Cases)• AnalyseAnalyse (recherche des abstractions principales

composant le système: classes et objets)• ConceptionConception des abstractions principales et

implantation d ’abstractions secondaires• ProgrammationProgrammation des abstractions dans un langage

orienté objet• TestsTests du système


6

Types de visualisation dans UML

Composantes

ConcurrenceRépartition

Use-Case

Logique


7

Visualisation « Use Cases »Use Cases »

Use-Case


8

Use casesUse cases• Décrivent la fonctionnalitéfonctionnalité

d ’un système• S’adressent aux clientsclients,

concepteursconcepteurs, responsablesresponsables du développementdéveloppement, responsablesresponsables des teststests

• Un Use Case décrit un point point fonctionnelfonctionnel du système

• Le fonctionnement globalfonctionnement global du système est décrit par l’ensemble des Use Casesl’ensemble des Use Cases

Assuré

Contracter une police d'assurance

Compiler statistiquesdes ventes Assureur

Compiler statistiquesdes clients


9

Use Cases dans UML

• Sont représentés par une ellipseellipse dans laquelle est inscrit le nom du Use Case

• Sont généralement connectés à un acteuracteur avec une association

Symbole UML d ’un Use Case

Symbole UML d ’un acteur

Symbole UML d ’une associationActeur

UseCase


10

Liens entre Use Cases

• « extendsextends » signifie qu ’un Use Case est une spécialisation d ’un autre Use Case plus général. Le Use Case plus spécifique n ’inclut pas nécessairement tout le comportement du Use Case qu ’il spécialise

• « usesuses » signifie qu ’un Use Case utilise intégralement la fonctionnalité du Use Case plus général en plus de lui ajouter des fonctionnalités additionnelles


11

Description d ’un Use Case

• ObjectifsObjectifs du Use Case• FlotFlot des messagesmessages entre l ’acteur’acteur et le Use CaseUse Case• Flot secondaireFlot secondaire des messages entre l ’acteur et le

Use Case• Condition de finCondition de fin pour le Use Case et information information

retournéeretournée à l ’acteur lors qu ’il se termine


12

Qu’est-ce qu’un bon Use Case

• Un bon Use Case représente une fonctionnalitéfonctionnalité du système qui est complètecomplète du début jusqu ’à la fin.

• Un bon Use Case doit normalement apporter quelque chose de valable à un acteur (i.e. un résultat résultat tangibletangible à une de ses commandes ou à une de ses actions sur le système.

• Il n ’y a pas de consensus sur la « grosseurgrosseur » que devrait prendre un Use Case en termes de fonctionnalité.


13

Visualisation « Logique Logique »»

Logique


14

Types de visualisation logique

Visualisation statiquestatique

Visualisation dynamiquedynamique


15

Visualisation statiquestatique

de Classes d'Objets

Diagrammes


16

Visualisation dynamiquedynamique

d'états séquentiels de collaboration d'activité

Diagrammes


17

Vision statiqueVision statique

Diagrammes de classesclasses


18

ClassesClasses et objetsobjets• Une classeclasse sert à décrire de manière génériquegénérique une

catégoriecatégorie d ’objets participant aux actions du système

• Un objetobjet est relié à une classe de la même manière qu ’une variablevariable est associée à un typetype de données dans un langage de programmation procéduralprocédural

• Les fondements de la programmation orientée objet sont les classesclasses, les objetsobjets, et les relationsrelations entre eux.

• Ces classesclasses, objetsobjets, et relationsrelations sont représentés par des diagrammesdiagrammes en langage UMLUML


19

Diagramme de classes

• est un modèle statiquestatique du système• décrit le système en termes de ses classesclasses et des

relationsrelations entre celles-ci• sert de basebase aux autres diagrammes où d ’autres

facettes du système sont décrites (tels les diagrammes d ’états des objets ou les diagrammes de collaboration qui sont des diagrammes dynamiques)


20

Recherche des classes• La recherche des classes est une étape de créationcréation.• pour trouver les classes pertinentes à un problème, il

faut se poser les questions suivantes:– Est-ce qu ’une information doit être analyséeanalysée ou stockéestockée?– Est-ce que le système interagit avec d ’autres systèmes’autres systèmes?– Existe-t-il des patronspatrons, des librairieslibrairies, ou des composantescomposantes

réutilisablesréutilisables dans le système?– Le système doit-il manipuler des périphériquespériphériques

(« devices »)?– Quels rôles les acteursacteurs jouent-ils?– Le système possède-t-il des pièces structuralespièces structurales (parts) (parts)?


21

Types classiques de classes

• EntityEntity: servent à modéliser des catégories d ’objetscatégories d ’objets qui ont une durée de vie importantedurée de vie importante dans le système (i.e. elles sont des parties intégrantes du système)

• BoundaryBoundary: servent à faciliter la communicationcommunication des classes Entity avec l ’extérieur’extérieur du système (soit un autre système, avec l ’utilisateur ou encore avec un périphérique)

• ControlControl: servent à coordonnercoordonner les échanges de messages entre les autres classes pour réaliser un Use case


22

Représentation des classes en UML• une classeclasse est représentée par

un rectanglerectangle divisé en trois trois compartimentscompartiments:– le compartiment du nomnom– le compartiment des attributsattributs– le compartiment des opérationsopérations

• la syntaxe dans les différents compartiments est indépendanteindépendante des langages de programmation

nom

attributs

operations()


23

Compartiment de nom

• Contient le nom de la classe• centré dans le compartiment• imprimé en caractères gras nom

attributs

operations()• Le nom ne doit pas être

ambigu• il doit être tiré du domaine

propre au problème


24

Compartiment des attributs• Les attributsattributs servent à décrire les caractéristiquescaractéristiques

des objets appartenant à la classe (i.e. décrivent l ’état’état de l ’objet)

• chaque attribut possède:– un typetype (primitif ou défini par l ’usager)– un niveau de visibiliténiveau de visibilité (publicpublic (+), protectedprotected (#) ou

privateprivate (-))– une valeur par défautvaleur par défaut– optionnellement, on peut aussi indiquer qu ’un attribut

possède une portéeportée s ’appliquant à la classeclasse (class scope)– …et une chaîne de propriétéschaîne de propriétés indiquant les valeurs que

peut prendre l ’attribut


25

Exemples de classe avec attributs

Auto

noEnregistrement : StringnbRoues : int = 4noPlaque : String

Private(-)

Protected(#)

Public(+)

type

Valeur pardéfaut


26

Compartiment des opérations• Les opérationsopérations permettent de manipulermanipuler les attributs

et d ’effectuer d ’autres actions. Elles sont appelées pour des instances (objets) de la classe.

• La signaturesignature des opérations comprend:– un typetype de retour– un nomnom– 0 ou plus paramètresparamètres (ayant chacun un type, un nom et

possiblement une valeur par défaut)– une visibilitévisibilité (private(-), protected(#), public(+))

• Les opérations constituent l ’interface’interface de la classe avec le monde extérieur


27

Exemple de classe avec opérations

Auto


getNoPlaque()demarre()pleinEssence()

Méthodes public


28

Spécification de l ’opération

• Pré-conditionsPré-conditions: doivent être vérifiées avant que l ’algorithme ne s ’exécute

• Post-conditionsPost-conditions: doivent être vraies une fois l ’opération complétée

• AlgorithmeAlgorithme: effet que l ’opération a sur l ’objet


29

Relations entre les classes

• Un diagramme de classes montre les classes d ’un système mais également les relationsrelations entre celles-ci:

• On compte quatrequatre principales catégories de relations entre classes:– les associationsassociations– les généralisationsgénéralisations (héritage)– les dépendancesdépendances– les raffinementsraffinements


30

Les associationsassociations de classes


31

Les associations

• Il existe plusieurs typestypes d ’associations:• normalenormale• récursiverécursive• agrégationagrégation par référenceréférence• agrégationagrégation par compositioncomposition


32

Association normale• Une association normale est une connexionconnexion entre classes• elle possède un nomnom• elle est généralement navigablenavigable de manière bidirectionnelle

(dans ce cas elle a un nom dans les deux sens si nécessaire)• elle a une multiplicitémultiplicité• elle peut être dotée de rôlesrôles

Auto


getNoPlaque()demarre()pleinEssence()

Personne

nom : Stringprenom : StringpermisConduire : Boolean = FALSE

getNom()getPrenom()getPermis()setNom()setPrenom()setPermis()

0..*possede 0..*

+conducteur +autoFlotte


33

Association récursive

• Une classe peut être connectée à elle-mêmeelle-même via une association récursive

• elle représente une connexion sémantiqueconnexion sémantique entre des objets mais avec la différence que ceux-ci appartiennent à la même même classeclasse

ContainerJava

0..*0..*


34

Les agrégationsagrégations de classes


35

Agrégation par référence• Indique une relation tout-tout-

partiepartie• se représente par une ligne

avec un losangelosange du côté « tout » de l ’agrégation. Ce losange ne peut apparaîtra qu ’à une seule extrémité

• elle possède des rôlesrôles, multiplicitémultiplicité, etc, comme une association normale

Wagon

Train

0..*

contient

0..*


36

Agrégation par composition• Indique une relation tout-tout-

partie avec inclusion partie avec inclusion « physique »« physique »

• se représente par une ligne avec un losangelosange pleinplein du côté « tout » de l ’agrégation. Ce losange ne peut apparaîtra qu ’à une seule extrémité

• elle possède des rôlesrôles, multiplicitémultiplicité, etc, comme une association normale

Cytoplasme

Cellule

1

contient

1

Chromosomes

Noyau

11

contient

1..*

contient

1..*


37

Les généralisationsgénéralisations de classes


38

Les généralisations• Une généralisation est une relationrelation entre une classe

généralegénérale et une classe plus spécifiquespécifique• la classe spécifique spécifique est appelée sous-classe sous-classe• la classe générale générale est appelée super-classe super-classe• la sous-classe hérite hérite des attributs attributs et opérations opérations de

la super-classe (en fonction de la visibilité de la généralisation)

• une sous-classesous-classe peut être la super-classesuper-classe d ’une autre classe dans ce que l ’on appelle une hiérarchiehiérarchie


39

Représentationdes généralisations• On représente les

généralisationsgénéralisations par une flècheflèche allant de la classe spécifique à la classe générale

• Lorsqu ’une classe spécifique hérite de plusieurs super-classes, on dit qu ’il y a héritage héritage multiplemultiple

Train

Wagon

noSerie : Integer = 0capacite : Double = 0.0longueur : Double = 0.0

getCapacite()getNoSerie()setNoSerie()setCapacite()getLongueur()setLongueur()

0..*0..*contient

Conteneur

hauteur : Double = 0.0largeur : Double = 0.0

setLargeur()getLargeur()setHauteur()getHauteur()setCapacite()

Citerne

diametre : Double = 0.0

getDiametre()setDiametre()setCapacite()

estUnestUn

généralisationgénéralisation


40

Interfaces• Les interfacesinterfaces sont des classes

contenant seulement des opérationsopérations sans implantationimplantation.

• Une classe peut implanterimplanter une interface

• Le symbole d ’implantation est une flèche pointilléeflèche pointillée allant de la classe versvers l ’interface

• Ici, la classe A implante les interfaces Storable et Runnable et B utilise ces implantations

Storable<<Interface>>

Runnable<<Interface>>

B

A

uses


41


Les PackagesPackages


42

Les Packages• Pour les systèmes comprenant plusieurs classes, il

convient de regrouper celles-ci en entités logiques, les packagespackages

• Un package est un ensemble de packagesensemble de packages et de classesclasses reliés sémantiquement entre eux

• Chaque package est muni d ’une interfaceinterface (ses classes publicclasses public) qui lui permet de communiquer sa fonctionnalité aux autres packages qui peuvent l ’importer


43

Les Packages (suite…)• Un package est représenté par un dossierdossier (folder)• Les Packages ont eux aussi un niveau de visibiliténiveau de visibilité

est des relationsrelations qui sont ici: la dépendancedépendance, le raffinementraffinement, et la généralisationgénéralisation

AssociationsSimples Agregations Heritage

InterfacesGUIClasses


44


Les TemplatesTemplates


45

Les Templates• UML supporte les

templatestemplates (aussi appelés « parameterized parameterized classesclasses »)

• Ils sont symbolisés par un symbole de classe avec symbole de classe avec un ajout identifiantun ajout identifiant le fait que le template doit être « instancié » avant de pouvoir créer des objets de la classe correspondant au template

T, n

Array

ColorArray

"bind" <color,50>

Array<Auto,100>

« Instanciation »

Raffinement


46

QualitésQualités d ’un modèle statique• Le modèle peut-il être

communiquécommuniqué aux autres membres de l ’équipemembres de l ’équipe de même qu ’au client client ?

• Le modèle a-t-il une utilitéutilité pour décrire le système?

• Le modèle embrasse-t-il les caractères essentielscaractères essentiels du système (permet-il entre autres de bien répéter les use-cases?

• Les noms des classesnoms des classes du modèle reflètent-ils les noms des éléments du noms des éléments du systèmesystème (i.e. les noms sont-ils pertinents)?

• Des modèles différentsmodèles différents de la même chosemême chose sont-ils intégrésintégrés et coordonnéscoordonnés entre eux?

• Les modèles sont-ils simplessimples (même pour les systèmes complexes?


47

OufOuf...


48

Visualisation « Dynamique Dynamique »»


49

Modélisation dynamique• Sert à montrer comment les

objetsobjets d ’un système collaborentcollaborent pour réaliser une fonctionnalitéfonctionnalité du système.

• Montre comment les objetsobjets s ’échangent des messagesmessages (i.e. comment un objet, le le clientclient, invoque une opérationopération sur un autre objet, le serveurle serveur). Ces échanges sont appelés interactionsinteractions.

• Les interactions sont montrées via trois principaux diagrammesdiagrammes:– séquenceséquence

– collaborationcollaboration

– activitéactivité

• Un autre diagramme, le diagramme d ’état décrit le comportement d ’un objet mais cette fois-ci pris isolément.


50

Les 4 modèles dynamiques• Diagramme d ’étatsDiagramme d ’états: décrit les étatsétats que peut

prendre un objet durant son cycle d ’existence et le comportementcomportement de ces états de même que les événementsévénements qui provoquent un changement d ’étatchangement d ’état de l ’objet

• Diagramme séquentielDiagramme séquentiel : montre comment les objets interagissentinteragissent et communiquentcommuniquent entre eux pour accomplir une tâchetâche du système. La variable indépendante est ici le tempstemps.


51

Les 4 modèles dynamiques (suite…)• Diagramme de collaborationDiagramme de collaboration: montre comment les

objets interagissentinteragissent et communiquentcommuniquent entre eux pour accomplir une tâchetâche du système. La variable indépendante est ici le l ’espacel ’espace. Par espace on entend ici les relations (liensliens) entre les objets dans le système.

• Diagramme d ’activitéDiagramme d ’activité: montre comment les objets interagissentinteragissent et communiquentcommuniquent entre eux pour accomplir une tâchetâche du système. La variable indépendante est ici le le travail accompli par les le travail accompli par les objets.objets.


52

Interactions entre les objets (messages)

• En programmation orientée objet, les interactions entre les objets sont modélisées comme des messagesmessages envoyés d ’un objet à un autre

• Ces messages sont simplement des appels appels d ’opérationsd ’opérations d ’un objet par un autre avec le contrôle qui revient à l ’objet appelant avec une valeur de retourvaleur de retour

SynchroneSynchrone

AsynchroneAsynchrone

SimpleSimple

SynchroneSynchroneavec retouravec retourimmédiatimmédiat


53

Le diagramme d ’étatsdiagramme d ’états


54

Le diagramme d ’états• Il sert à décrire le cycle de viecycle de vie d ’objets’objets, de sous-sous-

systèmessystèmes, et de systèmessystèmes• Il montre les étatsétats que les objets peuvent prendre et

comment les événementsévénements (messages reçusmessages reçus, temps temps écouléécoulé, occurrence d ’erreursoccurrence d ’erreurs, conditions conditions logiquement vraieslogiquement vraies)

• Un tel diagramme doit être associé à toute classe dont les objets peuvent prendre des états identifiables. Il décrit le comportementcomportement de ces objets et comment celui-ci évolueévolue en fonction de l ’état ’état présentprésent


55

AuPremierEtageEnAscension

entry: delai = 0do: MonteAL'etageexit: sonette.ring(bip)

PointMort

arrivé

EnDescente

do: descendAL'etagearrivé

EnDeplacementVersLePremierEtage

arrivé

monte( noEtage )

monte( noEtage )

descend( noEtage )

[ delai=delaiMinutes ]

Exemple

Ascenseur

etageCourant : Integer = 1delai : Integer = 0<<const>> delaiMinutes : Integer = 3

monte()descend()

Nom de l ’étatTransition

Actions

Etat de départ


56

Diagrammes d ’états - détails• Ces diagrammes peuvent

avoir un seulun seul point de point de départdépart et plusieursplusieurs points points d ’arrivéed ’arrivée

• Un point de départdépart est symbolisé par un disquedisque.

• Un point d ’arrivée’arrivée est symbolisé par un cerclecercle circonscrivant un disquedisque

• Un étatétat est symbolisé par un rectangle aux coins rectangle aux coins arrondisarrondis

• Les transitionstransitions sont symbolisées par une flècheflèche

Point de départ

Point d ’arrivée

Etat

Transition


57

Etats• En UMLUML, un état comprend 33

compartiments. Seulement 22 sont disponibles dans RoseRose (notation de State Charts de Harel).

• Le premierpremier compartiment contient le nomnom de l ’état

• Le secondsecond compartiment contient les actionsactions (aussi appelées événementsévénements) effectuées en entrantentrant (entryentry), durantdurant (dodo), en quittantquittant l ’état (exitexit), ou sur une conditioncondition

EnAscension

entry: delai = 0do: MonteAL'etageexit: ^sonette.ring(bip)

• Les événementsévénements peuvent être des actionsactions (do) ou des « sendsend »

Actions

Send


58

Etats (suite…)La syntaxe pour les actionsactions dans un état est la suivante:

Event-name argument list / action expression

La syntaxe pour la transitiontransition entre les états est la suivante:

Event-signature [guard-condition] / action expression ^ send-clause

Event-name (parameter, parameter, ...)

Destination-expression.destination-event-name (argument,...)


59

La signature des événements• Elle consiste en un nomnom d ’événement, une liste de liste de

paramètresparamètres séparés par des virgules. Le type des paramètres peut être indiqué comme suit:

Parameter-name : type-expression, Parameter-name: type-expression,...

Exemples:Dessine(f:Forme,c:couleur)redessine()redessineimprime(facture)


60

Condition de garde

• C ’est une expression booléenneexpression booléenne placée sur une transition d ’état.

• Si elle est combinée à un signature d ’événement, l ’événement et la condition de garde doivent tous tous les deuxles deux être vérifiés pour que la transition ait lieu.

• Exemples de conditions de garde:

[t = 15 sec][nombre de factures = 20]retrait(montant) [solde >= montant]

Conditions seules

Avec événement


61

Expression d ’action sur une transition• Elle consiste à une action procéduraleaction procédurale qui

s ’exécute lors de la transition. Elle peut s ’exprimer comme un appel d ’opérationappel d ’opération sur l ’objet proprement dit ou comme paramètres dans la paramètres dans la signature de l ’événementsignature de l ’événement.

• Il peut y avoir plusieurs actionsplusieurs actions lors d ’une transition mais il faut les séparer par un « / »

• Exemples de transitions avec actions:

Augmente()/n:=n+1/m:=m+1additionne(n)/somme := somme + n/clignote

Avecévénement

Sans


62

La send-clause

• C ’est un cas spécial d ’action’action.• Elle utilise une syntaxe explicite pour illustrer l ’envoi

d ’un message durantdurant la transition entre deux états.• Par exemple, l ’action suivante:

[temps = max]/descend(premierEtage)• peut s ’écrire avec la syntaxe de send-clause:

[temps = max]^self.descend(premierEtage)


63

Les événements• Représentent une chose qui

se produit et qui peut déclencher une actionaction.

• La relationrelation entre un événementévénement et une actionaction est causalecausale (i.e. ne peut être probabiliste)

• UML considère quatrequatre types principaux d ’événements:– Une conditioncondition qui devient

« vraie » (représentée par une «guard conditionguard condition »)

– la réceptionréception explicite d ’un signalsignal par l ’objet (le signal est lui-même un objet). On appelle ceci un messagemessage)

– la réception d’un appel appel d’opérationd’opération par un autre objet (ou par l’objet lui-même). Il s ’agit également d ’un messagemessage)

– l ’écoulement’écoulement d ’une période de tempstemps donnée (représentée par une expression temporelleexpression temporelle sur la transition)


64

Exemple d ’un diagramme d ’état

Affichage

do: affiche temps actuel

AjusteHeures

do: afficheHeuresAjusteMinutes

do: afficheHeures

inc / heures:=heures+1 inc / minutes:=minutes+1

boutonDeMode boutonDeMode

boutonDeMode

MontreNumerique

boutonDeMode()incremente()

MontreNumerique

boutonDeMode()incremente()


65

Le diagramme séquentielsdiagramme séquentiels


66

Les diagrammes séquentielsséquentiels

• Ils illustrent comment les objetsobjets interagissent entre eux.

• Ils se concentrent sur la séquence des messages séquence des messages envoyés entre les objetsenvoyés entre les objets (c ’est-à-dire commentcomment et quandquand les messages sont envoyés et reçus entre les objets)

• Ils possèdent deux axesdeux axes: l ’axe vertical’axe vertical montre le tempstemps tandis que l ’axe horizontal’axe horizontal montre l ’ensemble des objets en interactionobjets en interaction dans un scénarioscénario ou une scènescène spécifique d ’un scénario.


67

Les diagrammes séquentiels ...séquentiels ...

• Ils peuvent être utilisés sous deux formesformes:– forme génériqueforme générique: elle décrit toustous les déroulements

possibles d ’un scénario et peut contenir des branchementsbranchements, des conditionsconditions, et des bouclesboucles.

– forme d ’instanciationforme d ’instanciation: elle décrit le comportement du système pour un aspect spécifiqueaspect spécifique d ’un scénario et ne peut donc contenir aucunaucun branchementbranchement et aucune conditioncondition ou boucleboucle.


68

Les messages dans les diagrammes séquentiels• Ils représentent une communicationcommunication entre objets

véhiculant une informationinformation avec l ’anticipation qu ’une actionaction sera entreprise (comme pour les diagramme d ’états)

• La réceptionréception d ’un messagemessage est généralement appelée événementévénement.

• Les messagesmessages peuvent être des signauxsignaux («signals»), des appels d ’opérationappels d ’opération (ou quelque chose de semblable comme un RPCRPC ou une RMIRMI en Java)


69

Les messages ...• Quand un objet reçoit un message, on dit qu ’il entre

dans sa phase d ’activation. Un objet dans cette phase peut:– exécuter son propre code– attendre les résultats retournés par un autre objet à qui il a

envoyé un message

• L ’activation d ’un objet est représentée par un rectangle étroit sur la ligne de vie de l ’objet

• L ’exemple suivant montre un diagramme séquentiel simple pour les échanges entre une imprimante et un ordinateur


70

Diagramme des classes de l ’exemple

FileImprimante

Print()

QueueImpression

Store()

ServeurImprimante

Print()

Acteur

(from Use Case View)

Ordinateur

Print()


71

Diagramme séquentiel de l ’exemple

: Acteur

: Ordinateur : ServeurImprimante

: Imprimante : QueueImpression

Print(File) Print(File)Print(File)

Store(File)

Si imprim. libre

Si imprim. occupée

Messagesynchrone

Nom dumessage

Retour Lignesdevie

Activationde l ’objet

Objets


72

Le diagramme de collaboration collaboration


73

Les diagrammes de collaboration collaboration

• Les diagrammes de collaboration montrent les interactionsinteractions et les liensliens entre un ensemble d ’objets participant à un scénario.

• Ils focalisent leur attention sur l ’aspect spatial’aspect spatial des interactions.

• Ils sont particulièrement utiles pour montrer la réalisation de use-casesréalisation de use-cases (sans que les aspects temporels des interactions ne soient nécessairement rendus explicites).


74

Les diagrammes de...

• Les objetsobjets sont dessinés comme des classesclasses mais leurs nomsnoms sont soulignéssoulignés.

• Les liensliens sont illustrés par des ligneslignes (qui ressemblent à des lignes d ’associations dans les diagrammes de classes mais sans les informations de multiplicité).

• Un messagemessage, accompagné d ’une étiquetteétiquette, peut être associé à un lien pour montrer le senssens et l ’ordonnancement’ordonnancement de la transmission du message.


75

Les diagrammes de...• Les étiquettes de message associées aux liens

adoptent la syntaxe suivante:

Predecessor guard-condition sequence-expression return-value := signature

Expression pour la synchronisation synchronisation de threadsde threads signifiant que les messages reliés à des numéros de séquence spécifiques doivent être traités avant que le message courant soit transmis.

ConditionCondition à vérifier avant de transmettre le messageSyntaxe:[condition]

Syntaxe:[integer] | name] [recurrence] :integer: numéro dans la séquencename: thread de contrôlerecurrence: répétition.Syntaxe:* [iteration-clause] [condition-clause]

La «return-value» doit être affectée à la valeur retournée par la signaturesignature du message


76

Les liensliens dans les diagrammes de collaboration

• Un lienlien indique une connexionconnexion entre deux objets.• Le rôlerôle de chaque objet peut être inclus aux

extrémités de la connexion avec les qualificatifs du lien (rappel: les rôles et qualificatifs sont aussi inclus dans le diagramme de classe)

• Le stéréotypestéréotype du lien peut aussi être inclus dans la connexion.

• On compte les stéréotypesstéréotypes suivants:– globalglobal, locallocal, parameterparameter, selfself, votevote, broadcastbroadcast


77

Les stéréotypesstéréotypes de liensliens• GlobalGlobal: associé à un rôle du lien pour montrer que

l ’instanciation en présence est globaleglobale (visible dans tout le système).

• LocalLocal: associé à un rôle du lien pour montrer que l ’instanciation est une variable locale dans une opération.

• ParameterParameter: montre que l ’instance est visible parce que c ’est un paramètre d ’une opération

• SelfSelf: montre qu ’un objet peut s ’envoyer des messages

• VoteVote: contrainte imposée à un message limitant l ’éventail des valeurs de retour (spécifie que la valeur de retour est choisie au vote majoritaire entre différentes valeurs de retour)

• BroadcastBroadcast: contrainte appliquée à un ensemble de messages pour signifier qu ’ils ne sont pas exécutés dans un ordre donné


78

Exemple pour l’ascenseur : ClassesClasses

Requête

CreeDemande()

QueueAscenseur

AppelleJob()RecupereJob()

ControleurAscenseur

AppelAscenseur()

+jobBoutonAscenseur

presser()

Acteur

(from Use Case View)

Ascenseur

etageCourant : Integer = 1delai : Integer = 0<<const>> delaiMinutes : Integer = 3

monte()descend()

(from Elevator)


79

Exemple pour l’ascenseur :CollaborationCollaboration

: QueueAscenseur

transient

: Requête

transient

: BoutonAscenseur

persistent

: ControleurAscenseur

persistent

: Acteur

: Ascenseur

persistent

P

2: AppelAscenseur(int)

3: CreeDemande( )4: AppelleJob(job)

1: presser( )

5: RecupereJob( )

L

nextjob


80

Le diagramme de d ’activité d ’activité


81

Le diagramme d ’activités

• Focalise son attention sur l ’implantation’implantation des opérations dans les classes.

• Représente donc une façon de visualiser l ’activité ’activité interneinterne d ’un objet non pas en fonction des ses changements d ’états mais plutôt en termes des activités effectuées dans ces états.

• L ’implantation d ’une opération est vue comme une suite d ’actions’actions reliées entre elles. Ces actions sont par la suite transcrites en lignes de code.lignes de code.


82

Le diagramme d ’activités

• Les actionsactions sont représentées par des rectangles aux coins rectangles aux coins arrondis.arrondis.

• Les transitionstransitions entre les actions sont représentées par des flèchesflèches.

• Le diagramme comprend unun point de départdépart et unun ou plusieursplusieurs points d ’arrivée’arrivée.

• Un événementévénement peut accompagner la transition du point de départ seulement

• Des conditions de gardeconditions de garde, des «send-clausessend-clauses », et des actionsactions peuvent accompagner les transitions entre les actions.

• Des boîtes de décisionboîtes de décision (losanges) peuvent faire partie du diagramme.

• Des actionsactions peuvent être exécutés concurremmentconcurremment

• en les plaçant en parallèle sur le diagramme.


83

Le diagramme d ’activités. Exemple...

FenetreClients

ImprimeTousLesClients()

Affiche Message d'impression à l'écranFenetreClients.ImprimeTousLesClients()

CréeFichierPostscript

EffaceMessageEcran Imprimante.ImprimeFichier()

Send-clause

Action

TransitionDépart

Arrivée

Événement

Classe


84

OufOuf...


85

Architecture « physiquephysique »


86

Architecture physiquephysique• L ’architecture physique’architecture physique du système s ’intéresse à la

description détaillée de celui-ci sur les plans du hardwarehardware et du softwaresoftware.

• Elle illustre la structure du hardwarehardware en incluant les différents nœuds de calculnœuds de calcul et les liensliens entre ceux-ci

• Elle montre également la structurestructure, les dépendancesdépendances entre modules de logiciel qui implantent les concepts et les algorithmes de la description logique, et la distributiondistribution de ces modules en termes de processusprocessus, programmesprogrammes et composantescomposantes.


87

Architecture physiquephysique...• L ’architecture physique répond aux questions

suivantes:– Dans quels programmesprogrammes ou processusprocessus les classesclasses et

objetsobjets du modèle logique résidentrésident-ils physiquementphysiquement?– Sur quel(s) processeurprocesseur(s) ces programmesprogrammes et processusprocessus

s ’exécutent’exécutent-ils?– Quels types d ’ordinateurstypes d ’ordinateurs composent le système et

comment sont-ils reliés physiquementphysiquement?– Quelles sont les dépendancesdépendances entre les différents fichiersfichiers

ou packagespackages de classes (lors d ’un changement de fichier, quels autres fichiers doivent être recompilés)?


88

Architecture physiquephysique...

Mapping

•Composantes,•Processus•Ordinateurs

Physique

•Classes,•Objets,•Mécanismes,•Messages,•Algorithmes,

Logique


89

DiagrammesDiagrammes de l ’architecture physique

• En UMLUML, l ’architecture physique est principalement décrite par deuxdeux diagrammesdiagrammes:– le diagramme des composantesdiagramme des composantes (« component component

diagramdiagram »): contient les composantes logiciellescomposantes logicielles du projet (unités de code et fichiers concrets-binaires et sources).

– le diagramme de déploiementdiagramme de déploiement (« deployment diagram »deployment diagram »): décrit l ’architecture physique du run-time du système en couvrant les dispositifs physiquesdispositifs physiques (ordinateursordinateurs, processeursprocesseurs, etc.) et le logiciellogiciel qui leur est respectivement associé.


90

Le hardwarehardware

• La partie hardwarehardware d ’un système est divisée en troistrois éléments:– Les processeursprocesseurs: ce sont les ordinateurs qui exécutent les

programmes du système.

– Les «devicesdevices»: ce sont les périphériques de support tels les imprimantes, routeurs, lecteurs de disquettes/CD, etc. Ils sont généralement connectés à un processeur qui les contrôle. Il y a souvent peu de différence entre un processeur et un device.

– Les connexionsconnexions: ce sont les liens physiques entre les processeurs (câbles-fibre optique et/ou protocoles p.e. TCP/IP)


91

Le softwaresoftware• En UMLUML, un système logiciel est divisé en packages packages

de classesde classes• Un packagepackage rassemble un certain nombre de

classesclasses en un groupe logiquegroupe logique mais ne définit aucune sémantique pour le groupe.

• Il est fréquent d ’utiliser une ou quelques composantescomposantes du package comme façadefaçade du groupe. Cette façade est la seule partie visibleseule partie visible du groupe à l ’extérieur du package et constitue son interfaceinterface.

• Seule l ’interface’interface possède une dépendancedépendance avec d ’autres modulesmodules.


92

Le software...software...

• Un packagepackage contient un package de façadepackage de façade qui références d ’autres éléments mais qui ne contient lui-même aucun élément. Il est en quelque sorte le représentantreprésentant de son package.

• On lui donne le stéréotypestéréotype « façadefaçade » en UMLUML.• Il est aussi possible d ’utiliser une classe classe

d ’interfaced ’interface au package au lieu d ’un package de façade. Cette classeclasse devient une classe de façadeclasse de façade.


93

Le software...software...• Les principaux concepts servant à décrire la partie

software d ’un système sont:– Les composantescomposantes (« componentscomponents »): elles sont des parties

réutilisables qui offrent le packaging physiquepackaging physique d ’un ensemble d ’instanciations d ’éléments du modèle (par exemple, un fichier source) qui implantent des éléments du modèle logique.

– Les processusprocessus et les threadsthreads: ils représentent respectivement des flots de contrôleflots de contrôle « heavyweightheavyweight » et « lightweightlightweight ». Les deux sont décrits comme des classes classes actives stéréotypéesactives stéréotypées et les objets actifsobjets actifs correspondent à un component exécutablecomponent exécutable.

– Les objetsobjets: les objets passifspassifs sont ceux sanssans thread propre.


94

Le software...software...

• DeuxDeux principaux diagrammesdiagrammes servent à décrire physiquementphysiquement les systèmes:

les diagrammes de composantescomposantes (« componentscomponents »)

les diagrammes de répartitionrépartition (« deploymentdeployment » )


95

Le diagramme de composantes composantes(« component diagram »« component diagram »)


96

Le diagramme de composantes

• Il décrit les composantes logiciellescomposantes logicielles et leur interdépendanceinterdépendance.

• Il représente par conséquent la structurestructure du codecode.• Les composantescomposantes sont les implantations implantations

physiquesphysiques des conceptsconcepts et fonctionnalitésfonctionnalités définis dans le modèle logiquemodèle logique du système (i.e., les classesclasses, les objetsobjets, les liensliens et les collaborationscollaborations).

• Les composantescomposantes sont typiquement les fichiers fichiers d ’implantationd ’implantation des éléments logiques du système.


97

Les composantes• UMLUML définit trois types principaux de composantescomposantes:

– les composantes sourcescomposantes sources: ce type de composante prend toute sa signification lors de la compilationcompilation. Elle est un fichier source implantant une ou plusieurs classesclasses.

– Les composantes binairescomposantes binaires: elles représentent le code code objetobjet résultant de la compilation des sourcescompilation des sources. Il peut s ’agir d ’un fichier objetfichier objet, d ’une librairie statiquelibrairie statique, ou d ’une librairie dynamiquelibrairie dynamique. Une composante binairecomposante binaire prend toute sa signification lors de l ’édition des liens’édition des liens, dans le cas des librairies statiqueslibrairies statiques, ou au run-timerun-time, dans le cas des librairies dynamiqueslibrairies dynamiques.

– Les composantes exécutablescomposantes exécutables: programmesprogrammes résultant de l ’édition des liens des composantes binairescomposantes binaires.


98

Les composantes...• En UMLUML, une composantecomposante est représentée par un

grand rectanglegrand rectangle avec une ellipseellipse et deux petits deux petits rectanglesrectangles placés à la gauche du grand rectangle.

• Le nomnom de la composante est inscrit en dessous ou à l ’intérieur du grand rectangle.

• Les composantescomposantes sont des typestypes et seules les composantes exécutablesexécutables peuvent être instanciéesinstanciées.

• Les composantes instanciées sont montrées dans un diagramme de répartitiondiagramme de répartition où les différences instances de ces composantes sont allouées et où le processeur sur lequel elles s ’exécutent est montré.


99

Les composantes...• Les dépendancesdépendances entre composantes sont illustrées

par une ligne pointilléeligne pointillée avec une flèche simpleflèche simple.• Une dépendancedépendance signifie qu ’une composante a

besoin d ’une autre pour que sa définitiondéfinition soit complètecomplète.

• Dans un langage compilécompilé, si un module A dépend d ’un module B, cela signifie que module A doit être recompilé si des changements sont apportés à B.

• Si les composantes sont exécutablesexécutables, les dépendances montrent les librairies dynamiques qui sont nécessaires lors de l ’exécution d ’un programme.


100

Les composantes...

• Une composantecomposante peut avoir une interfaceinterface qui est visible aux autres composantes.

• Ces interfacesinterfaces peuvent être définies au niveau du code sourcecode source (comme en Java) ou au niveau du code exécutablecode exécutable utilisable au run-time (comme en OLE).

• Une interfaceinterface est montrée par une ligneligne terminée par un cerclecercle.

• Le nomnom de l ’interface’interface est inscrit près de ce cercle.


101

Exemple de diagramme de composantes de code sourcecomposantes de code source

Composante

Dépendancehome.html<<page>>

logoAnimation.java<<file>>

logoAnimation.doc<<document>>

animateur.java<<file>>

animateur.doc<<document>>


102

Exemple de diagramme de composantes run-timecomposantes run-time

commmanip.dll<<library>>

graphics.dll<<library>>

dbhandler.dll<<library>>

browser.exe<<application>>


103

Le diagramme de répartition répartition(« deployment diagram »« deployment diagram »)

Répartition


104

Le diagramme de répartitionrépartition• Ce diagramme montre l ’architecture run-time’architecture run-time des

processeursprocesseurs, des périphériquespériphériques, et des composantes logiciellescomposantes logicielles qui s ’exécutent sur cette architecture.

• Il est la description finaledescription finale de la topologie du topologie du systèmesystème car il unit les facettes hardwarehardware et softwaresoftware du système.

• Dans ce type de diagramme, il devrait être possible d ’observer un nœudnœud de la topologie et de voir les composantescomposantes qui s ’y exécutent, et quelles structures logiquesstructures logiques sont implantées dans ces composantes.


105

Diagramme de répartitionrépartition...

• Il comprend:– des nœudsnœuds– des connexionsconnexions– des composantescomposantes– des objetsobjets


106

Diagramme de répartitionrépartition...• NœudsNœuds: unités physiquesphysiques (matérielles) dotées

d ’une puissance de calculpuissance de calcul donnée (processeurs, imprimantes,lecteurs de cartes, périphériques de communication, etc). Les nœudsnœuds peuvent être des typestypes ou des instanciations de typesinstanciations de types. Un nœudnœud est représenté par un cube en trois dimensionscube en trois dimensions avec son nomnom à l ’intérieur (souligné si c ’est une instanciation)

• Les périphériquespériphériques sont aussi représentés par des nœudsnœuds avec un stéréotypestéréotype ou au moins un nom qui indique clairement que le nœud n ’en est pas un de calcul.


107

Processeur I

traiteData

preemptive

Processeur II

manual

acquisi tion

Imprimante Échantillonneur A/N

Ecran <<Vidéo>> <<TCP/IP>>

<<Parallèle>> <<BNC>>

Diagramme de répartitionrépartition…exemple simple

Nœud

Lien

Périphérique (device)

Process

Scheduling


108

OufOuf...


109

Un dernier exemple: le pattern proxyproxy en UML

Client Sujet

Requête()

<<Abstract>

SujetRéel

Requête()

Proxy

Requête()

refèreA->Requête();refèreA


110

Un dernier exemple: le pattern proxyproxy en UML

unClient : Client

unProxy : Proxy

unSujetRéel : SujetRéel

Requête( ) Requête( )


111

Processus de développement et UML


112

Processus de développementProcessus de développement de logiciel• UMLUML est un outil de modélisationmodélisation de systèmes.• Il doit être utilisé dans un contexte de

développementdéveloppement contrôlé par un processusprocessus orienté orienté objetobjet bien établi. Un outiloutil n ’est pas une méthodeméthode.

• Une méthodeméthode de design orientée objetorientée objet repose sur trois trois basesbases:

– une notationnotation permettant de décrire les modèlesmodèles;– un processusprocessus de construction des modèlesmodèles;– des outilsoutils facilitant la construction et la description des

modèles.


113

Le processus Le processus permet de...

• respecter les exigences fonctionnellesexigences fonctionnelles (parfois informelles) du système;

• se conformer aux limitesconformer aux limites de la machine exécutant le logiciel;

• se conformer aux ressources disponiblesressources disponibles;• satisfaire des critères de designcritères de design;• satisfaire les contraintescontraintes et les limiteslimites du

processus de designprocessus de design lui-même (un design doit être effectué dans un temps raisonnable).


114

Le processus Le processus doit permettre de limiter

• la complexitécomplexité du problèmeproblème; • la complexitécomplexité de gestion du processusprocessus de

conception du logiciel par une équipe d'ingénieurs: plusieurs solutions sont possibles et il faut choisir la meilleure;

• la complexitécomplexité associée à la flexibilitéflexibilité offerte par le logiciel;

• la complexitécomplexité associée à la difficulté de décrire des systèmes discretssystèmes discrets..


115

Le processus Le processus doit tenir compte du fait que...• Les systèmessystèmes adoptent une structure hiérarchiquestructure hiérarchique. • Le choix des composantes de basecomposantes de base de ces

systèmes est généralement arbitrairearbitraire; • Les liensliens intra-composantesintra-composantes sont généralement plus

forts que les liensliens inter-composantesinter-composantes; • Les systèmessystèmes sont généralement composés d'un

nombre restreint de sous-systèmessous-systèmes arrangésarrangés de diverses manières ou combinéscombinés de façons diverses;

• Les systèmessystèmes découlent de systèmes plus simplessimples dont ils sont une évolution.


116

OOA-OOD-OOP


117

OOA-OOD-OOPOOA-OOD-OOP• L ’analyse orientée objet’analyse orientée objet (OOA) est une méthode qui examine les

exigences d'un projet dans une perspective de classesclasses et d'objetsd'objets tirés du domaine de l'application.

• La conception orientée objetconception orientée objet (OOD) est une méthode de designdesign comprenant un processus ce décompositiondécomposition par objetsobjets et une notationnotation permettant de dépeindre les modèles logiques/physiquesmodèles logiques/physiques et statiques/ statiques/ dynamiquesdynamiques du système en cours de développement.

• La programmation par objetsprogrammation par objets (OOP) est une méthode d'implantationd'implantation par laquelle les programmes sont organisés en un ensemble d'objets un ensemble d'objets coopératifscoopératifs, chaque objet représentant une instance d'une classe, chaque classe faisant partie d'une hiérarchiehiérarchie de classes unies par des relations d'héritagerelations d'héritage.


118

ModélisationModélisation par objetsobjets• La modélisationmodélisation par objets comporte quatrequatre

éléments principauxprincipaux:

– l'abstractionl'abstraction: représentation des caractéristiques caractéristiques essentiellesessentielles d'un objet qui permettent de le distinguer de tous les autres;

– l'encapsulationl'encapsulation: processus de compartimentationcompartimentation des éléments d'une abstraction qui constituent sa structure et son comportement;

– la modularitémodularité: capacité qu'a un système d'être décomposé en un ensemble de modules cohérentscohérents et faiblement faiblement coupléscouplés;

– la hiérarchiehiérarchie: ordonnancementordonnancement d'abstractions;


119

ModélisationModélisation par objetsobjets• et troistrois éléments secondairessecondaires:

– le typagetypage: renforcement de la classe d'un objet telle que des objets de types différents ne puissent pas être intervertis;

– la concurrenceconcurrence: distingue un objet actifactif d'un objet inactifinactif. Un objet actif en est un qui représente un thread et implique les notions de synchronisation avec d'autres objets, ce qui n'est pas le cas des objets inactifs qui ne nécessitent pas de synchronisation temporelle avec les autres objets;

– la durabilitédurabilité: propriété grâce à laquelle un objet peut transcender le tempstemps (i.e. l'objet continue d'exister après que son créateur soit mort) et/ ou l'espacel'espace (i.e. l'espace mémoire occupé par l'objet se modifie par rapport à celui où il a été créé).


120

Modèle WATERFALL

ExigencesExigences

DesignDesign

ImplantationImplantation

TestTest

MaintenanceMaintenanceFlop!!!


121

Modèle WATERFALL(suite)Activité Phase

Design Codage Test Maintenance

Design 49.2 34.1 10.3 6.4

Codage 6.9 70.3 15.9 6.9

Test 4.7 43.4 26.1 25.8

!!!


122

Méthode de conception Unified


123

Méthode d ’analyse UnifiedUnifiedDévelopper un

modèle du système(analyse)

Développer unmodèle du système

(analyse)

Établir lesexigences centrales

du projet(conceptualisation)

Établir lesexigences centrales

du projet(conceptualisation)

Concevoir unearchitecture du

système(design)

Concevoir unearchitecture du

système(design)

Raffinerl ’implantationdu système(évolution)

Raffinerl ’implantationdu système(évolution)

Apporter lescorrectifs ausystème final

(entretien)

Apporter lescorrectifs ausystème final

(entretien)


124

Méthode d ’analyse UnifiedUnifiedIdentification des

classes etdes objets

Identification desclasses etdes objets

Identification dela sémantique des

classes et desobjets

Identification dela sémantique des

classes et desobjets

Identificationde la relation entre

les classeset les objets

Identificationde la relation entre

les classeset les objets

Définition del interface et

de l ’implantationdes classes et

des objets

Définition del interface et

de l ’implantationdes classes et

des objets


125

ApplicationApplication de la méthode

Processus itératif

Processus incrémental


126

Formation de l ’équipe’équipe

Architecte DéveloppeursIng. de

réutilisation

Contr. de qualité

Superviseur

Resp. doc.


127

AppelleAscenseurPassager


128

BoutonAppel

presser()

BoutonEtage

lum : VoyantLumineux

presser()

VoyantLumineux11<<hasA>>

Porte

statusOuverture : Boolean = false<<const>> noEtage : int

ouvre()ferme()getStatusOuverture()setStatusOuverture()

Ascenseur

arrivé : BooleanenMouvement : BooleanprochReq : RequêtenoEtageCourant : intnoEtageDestination : int

monte()descend()getArrivé()setArrivé()getenMouvement()setEnMouvement()getNoEtageCourant()setNoEtageCourant()getNoEtageDestination()setNoEtageDestination()

QueueRequêtes

PutRequête()GetRequête()

Requête

noEtage : int

getNoEtage()setNoEtage()Requête()

0..*0..*

<<hasA>>

ControleurAscenseur

appelleAscenseur()

Bouton

on : Boolean

<<abstract>> presser()getOn()

<<isA>> <<isA>>


129

Au premier étage

do: Attend

En Montée

do: vérifie no étage

monte( noEta )[ porte.statusOuverture = false ]

A l'arrêt

entry: commande ouverture portedo: Attend

[ arrivé=true ]monte( noEta )[ porte.statusOuverture=false ]

EnDescente

do: vérifie no étage

descend( noEta )[ porte.statusOuverture=false ]

[ arrivé=true ]


130

Fermée

entry: setStatusOuverture(false)

Ouverte

entry: setStatusOuverture(true)

ferme()[ Ascenseur.getEnMouvement() = false ]

ouvre()[ Ascenseur.getNoEtage(Destination)=noEtage ET Ascenseur.getEnMouvement() = false ]


131

Denis : PassagerMonterEtage1 : Bouton

Appel : ControleurAscenseur

ReqCourante : Requête

: QueueRequêtesNordEst : Ascenseur

presser( )appelleAscenseur(n) Requête(n)

PutRequête(ReqCourante)

GetRequête( )

getNoEtage( )


132

Denis : Passager

MonterEtage1 : BoutonAppel

: ControleurAscenseur

ReqCourante : Requête

: QueueRequêtes

NordEst : Ascenseur

G

G

1: presser( )

G

G

2: appelleAscenseur(n)

L

3: Requête(n)G

L

4: PutRequête(ReqCourante)

L

L

G

6: getNoEtage( )

P

G

5: GetRequête( )

modélisation par uml 1 denis laurendeau, p.h.d., ing. département de génie électrique et de...

Documents