Liste des questions théoriques pour l’examen final :

1. Le polymorphisme :
Le terme polymorphisme est certainement celui que l'on appréhende le plus. Mais il ne faut pas s'arrêter
à cela. Afin de mieux le cerner, il suffit d'analyser la structure du mot : poly comme plusieurs
et morphisme comme forme. Le polymorphisme traite de la capacité de l'objet à posséder plusieurs
formes.
Attention !
Le concept de polymorphisme ne doit pas être confondu avec celui d'héritage multiple. En effet,
l'héritage multiple - non supporté par le Pascal standard - permet à un objet d'hériter des membres
(champs et méthodes) de plusieurs objets à la fois, alors que le polymorphisme réside dans la capacité
d'un objet à modifier son comportement propre et celui de ses descendants au cours de l'exécution.
a. Règles de compilation
- Le compilateur connaît SEULEMENT le type de référence
- Peut seulement regarder dans la classe de référence pour la méthode
- Donne à la sortie la signature de la méthode
b. Règles d'exécution
- Suivez le type d'objet d'exécution exact pour trouver la méthode
- Doit faire correspondre la signature de la méthode de compilation à la méthode approprié
dans la classe de l'objet en cours
c. Casting
Casting est la conversion d'une expression d'un certain type en une expression d'un autre type.
Un opérateur cast est un opérateur unaire, qui a un seul opérande droit. La représentation physique de
l'opérateur cast est le nom d'un type à l'intérieur d'une paire de parenthèses correspondantes, comme dans:
(int)
Appliquer un opérateur de casting
L'application d'un opérateur de distribution au nom d'une variable ne change pas réellement le type de la
variable. Cependant, cela fait que le contenu de la variable est traité comme un type différent pour
l'évaluation de l'expression dans laquelle l'opérateur cast est contenu.
Passage automatique du type (comme int vers double)
• Superclass ref = new Subclass(); // Élargissement!
Explicit casting (comme double vers int)
• Subclass ref = (Subclass) superRef; // Rétrécissement!
FAITES ATTENTION:
Le compilateur vous fait confiance!
2. Classes et méthodes abstraites. Interfaces :
a. Java 8 et les interfaces
À partir de Java 8, on peut ajouter deux éléments supplémentaires dans une interfaces : des
méthodes statiques et des méthodes par défaut.
Méthode statique dans une interface
Une méthode statique est un élément que l'on peut rencontrer dans une classe normale. Un appel
statique se fait au travers de la classe, il n'a besoin d'aucune instance pour être exécuté. Java 8
autorise des méthodes statiques dans les interfaces, qui obésissent aux mêmes règles que celles que
l'on trouve dans les classes abstraites ou concrètes.
Exemple
public interface Function<T, R> {
R apply(T t) ;
static <T> Function<T, T> identity() {
return t -> t ; }}
 Méthode par défaut
Du point de vue technique, une méthode par défaut ressemble à s'y méprendre à une méthode
concrète, écrite dans une interface.
Exemple
public interface List<T> {
default void sort(Comparator<t> comparator) {
Collections.sort(this, comparator) ; }}
Une méthode par défaut permet d'écrire une méthode dans une interface, en fixant sa signature et en
donnant une implémentation.
b. Utilité et utilisation des interfaces
Les interfaces ont été conçues pour traiter la problématique des propriétés transverses. Prenons deux
exemples, tirés de l'API standard du JDK.
L'interface Serializable est utilisée comme un tag. Cette interface ne comporte aucune méthode, sa
seule fonction est de marquer les classes qui pourront être "sérialisées", c'est-à-dire dont les instances
pourront être écrites dans des fichiers ou transmises via un réseau.
L'interface Comparable est ajoutée à certaines classes, comme les classes enveloppe des types de
base, ou la classe String. Elle indique que les instances de ces classes peuvent être comparées au sens
d'un algorithme fourni par l'implémentation. Donc, on peut ranger des instances de Comparable dans
des ensembles auto-ordonnés. Nous verrons un exemple précis lorsque nous présenterons
l'API Collection.

3. Packages. Exceptions:
a. Pakages (Variable CLASSPATH, classloader)
Les paquets sont utilisés en Java pour éviter les conflits de noms, pour contrôler l'accès, pour
faciliter la recherche / localisation et l'utilisation de classes, d'interfaces, d'énumérations et
d'annotations, etc.
Un package peut être défini comme un regroupement de types connexes (classes, interfaces,
énumérations et annotations) fournissant une protection d'accès et une gestion des espaces de
noms.
Classpath est un paramètre de la machine virtuelle Java ou du compilateur Java qui spécifie
l'emplacement des classes et des packages définis par l'utilisateur. Le paramètre peut être défini
sur la ligne de commande ou via une variable d'environnement.
La variable d'environnement nommée CLASSPATH peut également être utilisée pour définir le
chemin de classe. Pour l'exemple ci-dessus, nous pourrions également utiliser sur Windows:
set CLASSPATH = D: \ monprogramme
Le ClassLoader est la partie de la JVM qui charge les classes en mémoire.
Lorsque nous compilons une classe Java, elle la transforme sous la forme d'un bytecode qui est
un programme compilé indépendant de la plate-forme et de la machine et le stocke en tant que
fichier de classe. Après cela lorsque nous essayons d'utiliser une classe, Java ClassLoader charge
cette classe en mémoire.
Java ClassLoader est hiérarchique et chaque fois qu'une requête est lancée pour charger une
classe, elle la délègue à son parent et, de cette manière, l'unicité est maintenue dans
l'environnement d'exécution. Si le chargeur de classe parent ne trouve pas la classe, le chargeur
de classe lui-même essaie de charger la classe.
b. Exceptions (déclanchement et capture)
Une exception est un signal qui se déclenche en cas de problème. Les exceptions permettent de
gérer les cas d'erreur et de rétablir une situation stable (ce qui veut dire, dans certains cas, quitter
l'application proprement). La gestion des exceptions se décompose en deux phases :
 La levée d'exceptions,
 Le traitement d'exceptions.
En Java, une exception est représentée par une classe. Toutes les exceptions dérivent de la
classe Exception qui dérive de la classe Throwable
Le traitement des exceptions se fait à l'aide de la séquence d'instructions try...catch...finally.
 L'instruction try indique qu'une instruction (ou plus généralement un bloc d'instructions)
susceptible de lever des exceptions débute.
 L'instruction catch indique le traitement pour un type particulier d'exceptions. Il peut y avoir
plusieurs instructions catch pour une même instruction try.
 L'instruction finally, qui est optionnelle, sert à définir un bloc de code à exécuter dans tous
les cas, exception levée ou non.
Il faut au moins une instruction catch ou finally pour chaque instruction try.

4. Type générique:
a. La programmation générique (classes et méthodes génériques)
Une classe qui peut faire référence à n'importe quel type est appelée classe générique. Nous
utilisons le paramètre de type T pour créer la classe générique de type spécifique.
Le type T indique qu'il peut faire référence à n'importe quel type (comme String, Integer,
Employee, etc.). Le type que vous spécifiez pour la classe sera utilisé pour stocker et
récupérer les données.
Ex:
class MyGen<T>{
T obj;
void add(T obj){this.obj=obj;}
T get(){return obj;}
}
Les méthodes génériques sont celles qui sont écrites avec une seule déclaration de méthode et
peuvent être appelées avec des arguments de types différents. Le compilateur assurera
l'exactitude de n'importe quel type est utilisé. Voici quelques propriétés des méthodes
génériques:
Les méthodes génériques ont un paramètre de type (l'opérateur du diamant englobant le type)
avant le type de retour de la déclaration de méthode
Les paramètres de type peuvent être bornés (les limites sont expliquées plus loin dans l'article)
Les méthodes génériques peuvent avoir différents paramètres de type séparés par des virgules
dans la signature de la méthode
Le corps de méthode pour une méthode générique est comme une méthode normale
b. Limites pour les variables de type, utilisation des sous-types et Type joker
ƒ Type joker permette de relâcher les contraintes sur les types paramétrés pour rendre des
méthodes plus réutilisables ƒ Faire une instanciation avec joker d’un type générique c’est donner
un type avec joker (« ? » est le joker) comme argument de type.
public static void paintAllBuildings(List<? extends Building> buildings) {
...}
Les caractères génériques sont représentés par le point d'interrogation dans Java "?" Et ils sont
utilisés pour désigner un type inconnu. Les caractères génériques sont particulièrement utiles lors
de l'utilisation de génériques et peuvent être utilisés en tant que type de paramètre, mais il y a
d'abord une note importante à prendre en compte

5. OOD et S.O.L.I.D. :
 a. La méthode de conception OOD simplifiée ;
La méthode O.O.D (object oriented design) de G.Booch propose 5 étapes dans l’établissement d’une
conception orientée objet. Cette démarche se révèle être utile pour un débutant et lui permettra de
fabriquer en particulier des prototypes avec efficacité sans trop surcharger sa mémoire.
- Identifier les objets et leurs attributs :
On cherchera à identifier les objets du monde réel que l’on voudra réaliser.
On cherchera ensuite à identifier les actions que l’objet subit de la part de son environnement et qu’il
provoque sur son environnement.
- Etablir la visibilité :
L’objet étant maintenant identifié par ses caractéristiques et ses opérations, on définira ses relations
avec les autres objets.
- Etablir l’interface :
Dès que la visibilité est acquise, on définit l’interface précise de l’objet avec le monde extérieur.
- Implémenter les objets :
La dernière étape consiste à implanter les objets en écrivant le code.
Nous n’opposons pas cette méthode de conception à la méthode structurée par machines abstraites.
Nous la considérons plutôt comme complémentaire (en appliquant à des débutants une idée contenue
dans la méthode HOOD). La méthode structurée sert à faire élaborer par l’étudiant des algorithmes
classiques comme des actions sur des données. La COO permet de définir le monde de
l’environnement de façon modulaire. Nous réutiliserons les algorithmes construits dans des objets
afin de montrer la complémentarité des deux visions.
b. Les principes de conception S.O.L.I.D.
En programmation informatique, SOLID est un acronyme représentant cinq principes de bases pour
la programmation orientée objet, introduits par Michael Feathers et Robert C. Martin au début des
années 2000. Ils sont censés apporter une ligne directrice permettant le développement de logiciel
plus fiable et plus robust.
- Responsabilité unique (single responsibility principle) - une classe, une fonction ou une
méthode doit avoir une et une seule responsabilité
- Ouvert/fermé (open/closed principle) - une classe doit être ouverte à l'extension, mais fermée à
la modification
- Substitution de Liskov (Liskov substitution principle) - une instance de type T doit pouvoir
être remplacée par une instance de type G, tel que G sous-type de T, sans que cela ne modifie la
cohérence du programme
- Ségrégation des interfaces (en) (interface segregation principle) - préférer plusieurs interfaces
spécifiques pour chaque client plutôt qu'une seule interface générale
- Inversion des dépendances (dependency inversion principle) - il faut dépendre des
abstractions, pas des implémentations

6. Recueillir les exigences :

Recueillir les exigences est le processus qui consiste à définir et à enregistrer les besoins des parties
prenantes nécessaires à l'atteinte des objectifs du projet dans un document approprié.
La réussite du projet est directement fonction du soin apporté au recueil et au management des exigences
du produit et du projet.
a. Les types d’exigence
- Exigences fonctionnelles - Elles décrivent les caractéristiques du système ou des processus que
le système doit exécuter. On trouve dans cette catégorie les règles métiers, et les exigences
fonctionnelles de sécurité (confidentialité,...). Elles correspondent aux fonctions principales et de
service de l’analyse fonctionnelle.
- Exigences non fonctionnelles - Elles décrivent les propriétés que le système doit avoir ; par
exemple les exigences techniques de sécurité informatique (confidentialité, intégrité,
 disponibilité), de performance, d'accessibilité, selon des critères définis. Elles correspondent aux
fonctions de contrainte de l’analyse fonctionnelle.
- Contraintes : Les limites du développement en quelque sorte : comme définir un système
d'exploitation sur lequel le système doit fonctionner, ou définir quel langage de programmation
doit être utilisé pour mettre en œuvre le système. Elles correspondent aussi aux fonctions de
contrainte de l’analyse fonctionnelle.
b. Le processus
- Rédaction des exigences - Les exigences doivent être écrites de telle manière qu'elles orientent
la création et la modification d'un système selon les règles métier (ou règles de gestion)
appropriées au contexte et au domaine et dans lequel le système doit être utilisé.
- Analyse des exigences - Les exigences sont sujettes à des problèmes d'ambiguïté,
d'imperfections, et d'incohérence. Des techniques telles qu'une inspection de logiciel rigoureuse
ont été présentées pour aider à traiter de tels problèmes. Lorsque les ambiguïtés, les
imperfections, et les incohérences sont résolues dans la phase d'exigences, l'ordre de grandeur du
coût de correction est moins élevé que lorsque ces mêmes problèmes se retrouvent dans des
étapes ultérieures de développement du produit. L'analyse des exigences s'efforce de résoudre
ces problèmes.
- Changements dans les exigences - Avec le temps, les exigences peuvent évoluer : c'est ce qui
est pris en compte dans les re conception de mi-vie d'un produit. De même durant un projet, un
cahier des charges peut être revu. Dans ce cas, la modification du cahier des charges contractuel
fait l'objet d'un avenant au contrat.
c. Les techniques

d. Les données d’entré

- Le plan de management des parties prenantes :est utilise pour comprendre les exigences des
parties prenantes en communication et leur niveau d’implication, pour les evaluer et les adapter
au niveau de participation des parties prenantes aux activites relatives aux exigences.
- Le registre des parties prenantes : c’est un document qui contient l’identification, l’evaluation et
la clasification des parties prenantes du projet
e. Les outils et techniques
- Entrteiens : est une approche formelle ou informelle permettant d’obtenir des informations de la
part des parties prenantes par un dialogue direct
- Groupes de consultation
- Ateliers diriges
- Techniques de creativite collective
- Techniques de prise de decision en groupe
- Questionnaire & enquetes
- L’observation
- Les prototypes
- Etalonnage
- Schemas contextuels
- Analyse de documents
f. Les données de sortir
- Documentation des exigences : contient les details des exigences et decrit comment chaque
exigence repond au besoin du projet(doit etre claire et non ambiguie, mesurable, coherente et
acceptable par les parties prenantes cles du projet)
- Matrice de tracabilite des exigences : c’est un tableau qui associe les exigences avec leurs
origines ou les parties prenantes l’ayant exprimees. Les attributs typiques utilises dans la matrice
 de tracabilite des exigences sont : un identifiant unique, une description textuelle de l’exigence,
le proprietaire, la source, la proirite...

7. Développement d'un projet informatique :

a. Appliquer réflexion et du bon sens
Le bon sens est la chose la mieux partagée au monde
Il est un principe de base et de bon sens qui veut que
ce qui se conçoit bien s'énonce clairement
Ce principe, énoncé par un poète français du 17ème siècle, prend tout son sens dès qu'il s'agit de
réaliser le moindre projet. Il dit, en substance, que l'on ne peut réaliser quoique ce soit de sérieux si on
a pas pris la peine au préalable de définir ce que l'on veut faire.
On peut y adjoindre les 4 préceptes du Discours de la Méthode de Descartes :
Ainsi, au lieu de ce grand nombre de préceptes dont la logique est composée, je crus que j'aurais
assez des quatre suivants, pourvu que je prisse une ferme et constante résolution de ne manquer
pas une seule fois à les observer.
b. Cycle en V
Le cycle en V est une formalisation du cycle de développement mettant en œuvre 5 étapes :
- définition ;
- conception ;
- réalisation ;
- intégration ;
- validation.
Chaque étape est matérialisée par un document :
- le document de définition ;
- le document de conception ;
- les fichiers sources et les tests unitaires ;
- le cahier de tests d'intégration ;
- le document de validation.
c. Le document de définition
Ce document décrit noir sur blanc le produit attendu en termes de :
- environnement ;
- interfaces ;
- comportement ;
- performances ;
- coûts et délais.
Il répond à la question "Quoi ?"
Ce document est connu du client et signé par celui-ci.
d. Le document de conception
Ce document décrit noir sur blanc les moyens mis en œuvre pour réaliser le produit :
- découpage arborescent en blocs fonctionnels ;
- architecture logicielle ;
- comportement détaillé (algorithmes, machines à états) ;
- fonctions (interfaces et comportement).
Il répond à la question "Comment ?"
Sauf indication contraire, ce document est interne.
e. Les fichiers sources et les tests unitaires
C'est le résultat du codage des fonctions. L'organisation du source ainsi que les interfaces des fonctions
publiques (points d'entrées) découlent de l'analyse résultant de la conception. Chaque bloc fonctionnel
terminal (feuille de l'arbre) est testé unitairement. Il est conçu pour être autonome, par exemple sous la
forme d'un composant logiciel. Si il a des sorties, celles-ci sont le plus souvent réalisées sous forme
d'appels à des fonctions externes via un pointeur de fonction, ce qui autorise les tests unitaires sans
connaître les détails de l'application.
Sauf indication contraire, ces documents sont internes.
f. Le cahier de test d'intégration
L'intégration consiste à rassembler les composants logiciels dans le but de réaliser le produit final. Une
liste de tests extrêmement poussés permet de valider la conception en fonctionnement normal, aux limites
et au-delà. L'ensemble de ces tests et leurs résultats sont consignés dans le cahier de test d'intégration.
C'est ici que se fait la mise au point du produit. Si un composant logiciel doit être corrigé (modifications
de spécifications détaillées), le test unitaire est repassé (éventuellement complété) afin de s'assurer qu'il
n'y a pas de régression et que le nouvel objectif est bien atteint.
Sauf indication contraire, ce document est interne.
g. Le document de validation
Le document de validation est une liste de tests 'boite noire' (c'est à dire que la conception est ignorée)
tendant à prouver la conformité du produit avec la demande du client. Il s'appuie bien sûr sur le document
de définition. On parle aussi de cahier de recette. Le fournisseur s'engage à réaliser les tests mentionnés et
à en indiquer les résultats. Il signe le document. C'est en quelque sorte la garantie constructeur. En cas de
litige, le client peut exiger qu'un test réputé réussi ou présentant des résultats connus, soit repassé devant
lui à des fins de vérification.
Ce document est connu du client et signé par le fournisseur et par le client.
h. Critique de la méthode du cycle en V
Le terme « en V » est issu de la mise en regard de chaque document et de leur portée :
 la validation est en regard de la spécification ;
 l'intégration est en regard de la conception ;
 la spécification et la validation sont du domaine du client.
Il en résulte le schéma suivant :
1 - Définition Validation - 5
\ / Domaine Client/Fournisseur
------------------------------------------------------------------
\ / Domaine Fournisseur
2 - Conception Intégration - 4
\ /
3 - Codage et TU
Théoriquement, la méthode en V est parfaite. Elle décrit un processus bien huilé qui transforme l'idée
du client en produit fini.
Dans la pratique, l'expérience montre que, loi de Murphy aidant, rien ne se passe comme prévu !
De nombreux facteurs s'acharnent à faire dériver le projet, que ce soit en matière de coût et de délai,
mais aussi, par exemple, en terme de faisabilité de telle ou telle fonctionnalité ou d'erreur de
conception grave (mauvais choix technologique, par exemple).
Tout le problème est donc de trouver le moyen d'identifier rapidement les obstacles et autres points
bloquants. Il existe pour ça des méthodes dites 'agiles' qui permettent d'obtenir des résultats bien
meilleurs que la méthode en V classique appliquée brutalement.
Ceci dit, les principes de la méthode en V sont bons, mais ils ne doivent pas être appliqués
directement à la réalisation de gros projets, mais sont utilisés d'une manière simplifiée mais
rigoureuse pour la réalisation des itérations courtes telles que les recommandent les méthodes dites
« agiles ».
i. Méthodes dites 'agiles'
Les méthodes agiles sont basées sur l'expérience et le bon sens. Plusieurs idées maîtresses régissent ces
méthodes. Elles visent avant tout à obtenir un résultat, et non à appliquer un formalisme rigide. La
méthode est centrée sur le produit. Elle n'est qu'un outil au service de la réalisation et non une fin en soi.
Les principales caractéristiques sont :
- les itérations courtes ;
- la conception par les tests ;
 - la réécriture ;
- le travail en binôme ;
- le travail en équipe.
j. L'architecture d'un système logiciel complexe
La vue logique constitue la principale description architecturale d'un système informatique et
beaucoup de petits projets se contentent de cette seule vue. Cette vue décrit, de façon statique et 7
dynamique, le système en termes d'objets et de classes. La vue logique permet d'identifier les
différents éléments et mécanismes du système à réaliser. Elle permet de décomposer le système en
abstractions et constitue le cœur de la réutilisation. En effet, l'architecte informatique récupérera un
maximum de composants des différentes bibliothèques et cadriciels (framework) à sa disposition. Une
recherche active de composants libres et/ou commerciaux pourra également être envisagée. La vue
logique est représentée, principalement, par des diagrammes statiques de classes et d'objets enrichis
de descriptions dynamiques : diagrammes d'activités, de séquence, diagrammes de communication ou
d'états-transitions.
k. Déterminer les exigences qui influencent l'architecture

l. Conception de l'architecture

m. Définition des composantes

n. Validation de l’architecture

8. Types d'architectures :
a. Concept
En informatique, architecture désigne la structure générale inhérente à un système informatique,
l'organisation des différents éléments du système
(logiciels et/ou matériels et/ou humains et/ou informations) et des relations entre les éléments. Cette
structure fait suite à un ensemble de décisions stratégiques prises durant la conception de tout ou partie du
système informatique, par l'exercice d'une discipline technique et industrielle du secteur de l'informatique
dénommée elle aussi architecture, et dont le responsable est l'architecte informatique.
La structure d'un système informatique n'est à ce jour assujettie à aucune norme. En matière de logiciels,
elle est représentée sous forme de graphiques tels que des organigrammes, des diagrammes
de workflow (flux de travaux en français) ou des diagrammes entité-relation. Le diagramme peut
concerner un logiciel, une pièce de matériel, un réseau informatique, un groupe de machines, un sous-
système, voire l'ensemble des dispositifs informatiques d'une entreprise ou d'une institution.
Un diagramme d'architecture est une perspective qui dépend du point de vue adopté par son auteur, en
fonction des éléments qu'il cherche à mettre en évidence. Le diagramme omet volontairement certains
détails pour rendre la perspective plus visible. Il peut y avoir plusieurs diagrammes d'architecture pour un
même système, tels que : architecture des informations, architecture métier, architecture applicative et
architecture technique
b. Mise en oeuvre

c. Style architectural

d. Style standards
 Liste des questions pratiques pour l’examen final (problèmes sur les sujets) :
Le polymorphisme.

/* File name : Employee.java */

public class Employee {

private String name;

private String address;

private int number;

public Employee(String name, String address, int number) {

System.out.println("Constructing an Employee");

this.name = name;

this.address = address;

this.number = number;

public void mailCheck() {

System.out.println("Mailing a check to " + this.name + " " + this.address);

public String toString() {

return name + " " + address + " " + number;

public String getName() {

return name;

public String getAddress() {

return address;

public void setAddress(String newAddress) {

address = newAddress;

}
 public int getNumber() {

return number;

public class Salary extends Employee {

private double salary; // Annual salary

public Salary(String name, String address, int number, double salary) {

super(name, address, number);

setSalary(salary);

public void mailCheck() {

System.out.println("Within mailCheck of Salary class ");

System.out.println("Mailing check to " + getName()

+ " with salary " + salary);

public double getSalary() {

return salary;

public void setSalary(double newSalary) {

if(newSalary >= 0.0) {

salary = newSalary;

public double computePay() {

System.out.println("Computing salary pay for " + getName());

return salary/52;

}
public class VirtualDemo {

public static void main(String [] args) {

Salary s = new Salary("Mohd Mohtashim", "Ambehta, UP", 3, 3600.00);

Employee e = new Salary("John Adams", "Boston, MA", 2, 2400.00);

System.out.println("Call mailCheck using Salary reference --");

s.mailCheck();

System.out.println("\n Call mailCheck using Employee reference--");

e.mailCheck();

Classes et méthodes abstraites.

public abstract class Person
{
#region fields for the abstrac class

protected string firstName;

protected string lastName;
protected int age;

#endregion

#region properties for the abstract class

public abstract string FirstName
{
get; set;
}

public abstract string LastName

{
get; set;
}

public abstract int Age

{
get; set;
}
#endregion

#region completed methods for the abstract class

string Add ()
{
return "New person " + firstName + " " + lastName + " added.";
 }

string Delete ()
{
return "Person" + firstName + " " + lastName + " deleted.";

#endregion

#region abstract method

public abstract int CalculateWage();

#endregion
}

Interfaces

interface Animal {

public void eat();

public void travel();

public class MammalInt implements Animal {

public void eat() {

System.out.println("Mammal eats");

public void travel() {

System.out.println("Mammal travels");

public int noOfLegs() {

return 0;

}
 public static void main(String args[]) {

MammalInt m = new MammalInt();

m.eat();

m.travel();

Exceptions

public class CheckingAccount {

private double balance;

private int number;

public CheckingAccount(int number) {

this.number = number;

public void deposit(double amount) {

balance += amount;

public void withdraw(double amount) throws InsufficientFundsException {

if(amount <= balance) {

balance -= amount;

}else {

double needs = amount - balance;

throw new InsufficientFundsException(needs);

public double getBalance() {

return balance;
 }

public int getNumber() {

return number;

public class BankDemo {

public static void main(String [] args) {

CheckingAccount c = new CheckingAccount(101);

System.out.println("Depositing $500...");

c.deposit(500.00);

try {

System.out.println("\nWithdrawing $100...");

c.withdraw(100.00);

System.out.println("\nWithdrawing $600...");

c.withdraw(600.00);

} catch (InsufficientFundsException e) {

System.out.println("Sorry, but you are short $" + e.getAmount());

e.printStackTrace();

Type générique

public class Box<T> {

private T t;

public void add(T t) {

 this.t = t;

public T get() {

return t;

public static void main(String[] args) {

Box<Integer> integerBox = new Box<Integer>();

Box<String> stringBox = new Box<String>();

integerBox.add(new Integer(10));

stringBox.add(new String("Hello World"));

System.out.printf("Integer Value :%d\n\n", integerBox.get());

System.out.printf("String Value :%s\n", stringBox.get());

Implémentation du code à partir de diagramme de séquence

public class CheckKeyDoorState extends CompositeDoorState {
public CheckKeyDoorState() {
init(DoorInterface.NOKEYCHECKKEYDOORSTATE); }
public CheckKeyDoorState(AbstractDoorState state) {
init(state); }
private void init(AbstractDoorState state)
{ setState(state);
add(DoorInterface.HASKEYCHECKKEYDOORSTATE);
add(DoorInterface.NOKEYCHECKKEYDOORSTATE); }
public AbstractDoorState checkKey() {
return changeState(getState().checkKey()); }
public AbstractDoorState leaveKey() {
return changeState(getState().leaveKey()); }
public AbstractDoorState stop() {
return changeState(getState().stop()); }
public AbstractDoorState enterKey() {
return changeState(getState().enterKey()); }
public AbstractDoorState entry() {
super.entry();
return getState().entry(); } }
Création des tests unitaires
import org.junit.runner.RunWith;

import org.junit.runners.Suite;

//JUnit Suite Test

@RunWith(Suite.class)

@Suite.SuiteClasses({

TestJunit1.class ,TestJunit2.class

})

public class JunitTestSuite {

import org.junit.Test;

import org.junit.Ignore;

import static org.junit.Assert.assertEquals;

public class TestJunit1 {

String message = "Robert";

MessageUtil messageUtil = new MessageUtil(message);

@Test

public void testPrintMessage() {

System.out.println("Inside testPrintMessage()");

assertEquals(message, messageUtil.printMessage());

import org.junit.Test;

import org.junit.Ignore;

import static org.junit.Assert.assertEquals;

public class TestJunit2 {

String message = "Robert";

MessageUtil messageUtil = new MessageUtil(message);

 @Test

public void testSalutationMessage() {

System.out.println("Inside testSalutationMessage()");

message = "Hi!" + "Robert";

assertEquals(message,messageUtil.salutationMessage());