 |
|
1) Introduction sur les « objets » |
|
|
|
|
| Texte original |
|
Traducteur :
Jérome Quelin |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Internet vs. intranet
|
|
Internet vs. intranet
|
|
|
|
The Web is the most general solution to
the client/server problem, so it makes sense that you can use the same
technology to solve a subset of the problem, in particular the classic
client/server problem within a company. With traditional client/server
approaches you have the problem of multiple types of client computers, as well
as the difficulty of installing new client software, both of which are handily
solved with Web browsers and client-side programming. When Web technology is
used for an information network that is restricted to a particular company, it
is referred to as an intranet. Intranets provide much greater security than the
Internet, since you can physically control access to the servers within your
company. In terms of training, it seems that once people understand the general
concept of a browser it’s much easier for them to deal with differences in
the way pages and applets look, so the learning curve for new kinds of systems
seems to be reduced.
|
|
Le Web est la solution la plus générique au problème du client/serveur, il
est donc logique de vouloir appliquer la même technologie pour résoudre ceux liés aux
client/serveur à l'intérieur d'une entreprise. Avec l'approche traditionnelle du
client/serveur se pose le problème de l'hétérogénéité du parc de clients, de même que les
difficultés pour installer les nouveaux logiciels clients. Ces problèmes sont résolus par les
browsers Web et la programmation côté client. Quand la technologie du Web est utilisée dans le
système d'information d'une entreprise, on s'y réfère en tant qu'intranet. Les intranets
fournissent une plus grande sécurité qu'Internet puisqu'on peut contrôler les accès physiques aux
serveurs à l'intérieur de l'entreprise. En terme d'apprentissage, il semblerait qu'une fois que les
utilisateurs se sont familiarisés avec le concept d'un browser il leur est plus facile de gérer les
différences de conception entre les pages et applets, et le coût d'apprentissage de nouveaux
systèmes semble se réduire.
|
|
|
|
The security problem brings us to one of
the divisions that seems to be automatically forming in the world of client-side
programming. If your program is running on the Internet, you don’t know
what platform it will be working under, and you want to be extra careful that
you don’t disseminate buggy code. You need something cross-platform and
secure, like a scripting language or Java.
|
|
Le problème de la sécurité nous mène à l'une des divisions qui semble se
former automatiquement dans le monde de la programmation côté client. Si un programme est distribué
sur Internet, on ne sait pas sur quelle plateforme il va tourner et il faut être particulièrement
vigilant pour ne pas diffuser du code buggué. Il faut une solution multiplateformes et sûre, comme
un langage de script ou Java.
|
|
|
|
If you’re running on an intranet,
you might have a different set of constraints. It’s not uncommon that your
machines could all be Intel/Windows platforms. On an intranet, you’re
responsible for the quality of your own code and can repair bugs when
they’re discovered. In addition, you might already have a body of legacy
code that you’ve been using in a more traditional client/server approach,
whereby you must physically install client programs every time you do an
upgrade. The time wasted in installing upgrades is the most compelling reason to
move to browsers, because upgrades are invisible and automatic. If you are
involved in such an intranet, the most sensible approach to take is the shortest
path that allows you to use your existing code base, rather than trying to
recode your programs in a new language.
|
|
Dans le cas d'un intranet, les contraintes peuvent être complètement
différentes. Le temps passé à installer les nouvelles versions est la raison principale qui pousse
à passer aux browsers, car les mises à jours sont invisibles et automatiques. Il n'est pas rare que
tous les clients soient des plateformes Wintel (Intel / Windows). Dans un intranet, on est
responsable de la qualité du code produit et on peut corriger les bugs quand ils sont découverts.
De plus, on dispose du code utilisé dans une approche plus traditionnelle du client/serveur où il
fallait installer physiquement le client à chaque mise à jour du logiciel. Dans le cas d'un
tel intranet, l'approche la plus raisonnable consiste à choisir la solution qui permettra de
réutiliser le code existant plutôt que de repartir de zéro dans un nouveau langage.
|
|
|
|
When faced with this bewildering array of
solutions to the client-side programming problem, the best plan of attack is a
cost-benefit analysis. Consider the constraints of your problem and what would
be the shortest path to your solution. Since client-side programming is still
programming, it’s always a good idea to take the fastest development
approach for your particular situation. This is an aggressive stance to prepare
for inevitable encounters with the problems of program
development.
|
|
Quand on est confronté au problème de la programmation côté client, la
meilleure chose à faire est une analyse coûts-bénéfices. Il faut prendre en compte les contraintes
du problème, et la solution qui serait la plus rapide à mettre en oeuvre. En effet, comme la
programmation côté client reste de la programmation, c'est toujours une bonne idée de choisir
l'approche permettant un développement rapide.
|
|
|
|
Server-side programming
|
|
La programmation côté serveur
|
|
|
|
This whole discussion has ignored the
issue of server-side programming. What happens when you make a request of a
server? Most of the time the request is simply “send me this file.”
Your browser then interprets the file in some appropriate fashion: as an HTML
page, a graphic image, a Java applet, a script program, etc. A more complicated
request to a server generally involves a database transaction. A common scenario
involves a request for a complex database search, which the server then formats
into an HTML page and sends to you as the result. (Of course, if the client has
more intelligence via Java or a scripting language, the raw data can be sent and
formatted at the client end, which will be faster and less load on the server.)
Or you might want to register your name in a database when you join a group or
place an order, which will involve changes to that database. These database
requests must be processed via some code on the server side, which is generally
referred to as server-side programming. Traditionally, server-side programming
has been performed using Perl and CGI scripts, but more sophisticated systems
have been appearing. These include Java-based Web servers that allow you to
perform all your server-side programming in Java by writing what are called
servlets. Servlets and their offspring, JSPs, are two of the most compelling
reasons that companies who develop Web sites are moving to Java, especially
because they eliminate the problems of dealing with differently abled browsers.
|
|
Toute cette discussion a passé sous silence la programmation côté serveur.
Que se passe-t-il lorsqu'un serveur reçoit une requête ? La plupart du temps cette requête est
simplement « envoie-moi ce fichier ». Le browser interprète alors ce fichier d'une
manière particulière : comme une page HTML, une image graphique, une applet Java, un programme
script, etc... Une requête plus compliquée à un serveur implique généralement une transaction vers
une base de données. Un scénario classique consiste en une requête complexe de recherche
d'enregistrements dans une base de données que le serveur formate dans une page HTML et renvoie
comme résultat (bien sûr, si le client est « intelligent » via Java ou un langage de script,
la phase de formatage peut être réalisée par le client et le serveur n'aura qu'a envoyer les
données brutes, ce qui allégera la charge et le trafic engendré). Ou alors un client peut vouloir
s'enregistrer dans une base de données quand il joint un groupe ou envoie une commande, ce qui
implique des changements dans la base de données. Ces requêtes doivent être traitées par du code
s'exécutant sur le serveur, c'est ce qu'on appelle la programmation côté serveur.
Traditionnellement, la programmation côté serveur s'est appuyée sur Perl et les scripts CGI, mais
des systèmes plus sophistiqués sont en train de voir le jour. Cela inclut des serveurs Web écrits
en Java qui permettent de réaliser toute la programmation côté serveur en Java en écrivant ce qu'on
appelle des servlets. Les servlets et leur progéniture, les JSPs, sont les deux raisons principales
qui poussent les entreprises qui développent un site Web à se tourner vers Java, en particulier
parce qu'ils éliminent les problèmes liés aux différences de capacité des browsers.
|
|
|
|
A separate arena: applications
|
|
Une scène séparée : les applications
|
|
|
|
Much of the brouhaha over Java has been
over applets. Java is actually a general-purpose programming language that can
solve any type of problem—at least in theory. And as pointed out
previously, there might be more effective ways to solve most client/server
problems. When you move out of the applet arena (and simultaneously release the
restrictions, such as the one against writing to disk) you enter the world of
general-purpose applications that run standalone, without a Web browser, just
like any ordinary program does. Here, Java’s strength is not only in its
portability, but also its programmability. As you’ll see throughout this
book, Java has many features that allow you to create robust programs in a
shorter period than with previous programming languages.
|
|
La plupart de la publicité faite autour de Java se référait aux applets.
Mais Java est aussi un langage de programmation à vocation plus générale qui peut résoudre
n'importe quel type de problème - du moins en théorie. Et comme précisé plus haut, il peut y avoir
des moyens plus efficaces de résoudre la plupart des problèmes client/serveur. Quand on quitte la
scène des applets (et les restrictions qui y sont liées telles que les accès en écriture sur le
disque), on entre dans le monde des applications qui s'exécutent sans le soutien d'un browser,
comme n'importe quel programme. Les atouts de Java sont là encore non seulement sa portabilité,
mais aussi sa facilité de programmation. Comme vous allez le voir tout au long de ce livre, Java
possède beaucoup de fonctionnalités qui permettent de créer des programmes robustes dans un laps de
temps plus court qu'avec d'autres langages de programmation.
|
|
|
|
Be aware that this is a mixed blessing.
You pay for the improvements through slower execution speed (although there is
significant work going on in this area—JDK 1.3, in particular, introduces
the so-called “hotspot” performance improvements). Like any
language, Java has built-in limitations that might make it inappropriate to
solve certain types of programming problems. Java is a rapidly evolving
language, however, and as each new release comes out it becomes more and more
attractive for solving larger sets of
problems.
|
|
Mais il faut bien être conscient qu'il s'agit d'un compromis. Le prix à
payer pour ces améliorations est une vitesse d'exécution réduite (bien que des efforts
significatifs soient mis en oeuvre dans ce domaine - JDK 1.3, en particulier, introduit le concept
d'amélioration de performances « hotspot »). Comme tout langage de programmation, Java a
des limitations internes qui peuvent le rendre inadéquat pour résoudre certains types de problèmes.
Java évolue rapidement cependant, et à chaque nouvelle version il permet d'adresser un spectre de
plus en plus large de problèmes.
|
|
|
|
Analysis and
design
|
|
Analyse et conception
|
|
|
|
The object-oriented paradigm is a new and
different way of thinking about programming. Many folks have trouble at first
knowing how to approach an OOP project. Once you know that everything is
supposed to be an object, and as you learn to think more in an object-oriented
style, you can begin to create “good” designs that take advantage of
all the benefits that OOP has to offer.
|
|
Le paradigme de la POO constitue une approche nouvelle et différente de la
programmation. Beaucoup de personnes rencontrent des difficultés pour appréhender leur premier
projet orienté objet. Une fois compris que tout est supposé être un objet, et au fur et à mesure
qu'on se met à penser dans un style plus orienté objet, on commence à créer de « bonnes »
conceptions qui s'appuient sur tous les avantages que la POO offre.
|
|
|
|
A method
(often called a methodology) is a set of processes and heuristics
used to break down the complexity of a programming problem. Many OOP methods
have been formulated since the dawn of object-oriented programming. This section
will give you a feel for what you’re trying to accomplish when using a
method.
|
|
Une méthode (ou méthodologie) est un ensemble de processus et
d'heuristiques utilisés pour réduire la complexité d'un problème. Beaucoup de méthodes orientées
objet ont été formulées depuis l'apparition de la POO. Cette section vous donne un aperçu de ce que
vous essayez d'accomplir en utilisant une méthode.
|
|
|
|
Especially in OOP, methodology is a field
of many experiments, so it is important to understand what problem the method is
trying to solve before you consider adopting one. This is particularly true with
Java, in which the programming language is intended to reduce the complexity
(compared to C) involved in expressing a program. This may in fact alleviate the
need for ever-more-complex methodologies. Instead, simple methodologies may
suffice in Java for a much larger class of problems than you could handle using
simple methodologies with procedural languages.
|
|
Une méthodologie s'appuie sur un certain nombre d'expériences, il est donc
important de comprendre quel problème la méthode tente de résoudre avant d'en adopter une. Ceci est
particulièrement vrai avec Java, qui a été conçu pour réduire la complexité (comparé au C) dans
l'expression d'un programme. Cette philosophie supprime le besoin de méthodologies toujours plus
complexes. Des méthodologies simples peuvent se révéler tout à fait suffisantes avec Java pour une
classe de problèmes plus large que ce qu'elles ne pourraient traiter avec des langages
procéduraux.
|
|
|
|
It’s also important to realize that
the term “methodology” is often too grand and promises too much.
Whatever you do now when you design and write a program is a method. It may be
your own method, and you may not be conscious of doing it, but it is a process
you go through as you create. If it is an effective process, it may need only a
small tune-up to work with Java. If you are not satisfied with your productivity
and the way your programs turn out, you may want to consider adopting a formal
method, or choosing pieces from among the many formal methods.
|
|
Il est important de réaliser que le terme «> méthodologie » est trompeur
et promet trop de choses. Tout ce qui est mis en oeuvre quand on conçoit et réalise un programme
est une méthode. Ca peut être une méthode personnelle, et on peut ne pas en être conscient, mais
c'est une démarche qu'on suit au fur et à mesure de l'avancement du projet. Si cette méthode est
efficace, elle ne nécessitera sans doute que quelques petites adaptations pour fonctionner avec
Java. Si vous n'êtes pas satisfait de votre productivité ou du résultat obtenu, vous serez
peut-être tenté d'adopter une méthode plus formelle, ou d'en composer une à partir de plusieurs
méthodes formelles.
|
|
|
|
While you’re going through the
development process, the most important issue is this: Don’t get lost.
It’s easy to do. Most of the analysis and design
methods are intended to solve the largest of problems.
Remember that most projects don’t fit into that category, so you can
usually have successful analysis and design with a relatively small subset of
what a method
recommends[8].
But some sort of process, no matter how limited, will generally get you on your
way in a much better fashion than simply beginning to code.
|
|
Au fur et à mesure que le projet avance, le plus important est de ne pas se
perdre, ce qui est malheureusement très facile. La plupart des méthodes d'analyse et de
conception sont conçues pour résoudre même les problèmes les plus gros. Il faut donc bien être
conscient que la plupart des projets ne rentrant pas dans cette catégorie, on peut arriver à une
bonne analyse et conception avec juste une petite partie de ce qu'une méthode recommande href="#fn8" name="fnB8">[8]. Une méthode de conception, même limitée, met sur la voie bien
mieux que si on commence à coder directement.
|
|
|
|
It’s also easy to get stuck, to
fall into “analysis
paralysis,” where you feel like you can’t move forward because you
haven’t nailed down every little detail at the current stage. Remember, no
matter how much analysis you do, there are some things about a system that
won’t reveal themselves until design time, and more things that
won’t reveal themselves until you’re coding, or not even until a
program is up and running. Because of this, it’s crucial to move fairly
quickly through analysis and design, and to implement a test of the proposed
system.
|
|
Il est aussi facile de rester coincé et tomber dans la « paralysie analytique » où on se dit qu'on ne peut passer à la phase suivante
car on n'a pas traqué le moindre petit détail de la phase courante. Il faut bien se dire que quelle
que soit la profondeur de l'analyse, certains aspects d'un problème ne se révéleront qu'en phase de
conception, et d'autres en phase de réalisation, voire même pas avant que le programme ne soit
achevé et exécuté. A cause de ceci, il est crucial d'avancer relativement rapidement dans l'analyse
et la conception, et d'implémenter un test du système proposé.
|
|
|
|
This point is worth emphasizing. Because
of the history we’ve had with procedural languages, it is commendable that
a team will want to proceed carefully and understand every minute detail before
moving to design and implementation. Certainly, when creating a DBMS, it pays to
understand a customer’s needs thoroughly. But a DBMS is in a class of
problems that is very well-posed and well-understood; in many such programs, the
database structure is the problem to be tackled. The class of programming
problem discussed in this chapter is of the “wild-card” (my term)
variety, in which the solution isn’t simply re-forming a well-known
solution, but instead involves one or more
“wild-card factors”—elements for which
there is no well-understood previous solution, and for which research is
necessary[9].
Attempting to thoroughly analyze a wild-card problem before moving into design
and implementation results in analysis paralysis because you don’t have
enough information to solve this kind of problem during the analysis phase.
Solving such a problem requires iteration through the whole cycle, and that
requires risk-taking behavior (which makes sense, because you’re trying to
do something new and the potential rewards are higher). It may seem like the
risk is compounded by “rushing” into a preliminary implementation,
but it can instead reduce the risk in a wild-card project because you’re
finding out early whether a particular approach to the problem is viable.
Product development is risk management.
|
|
Il est bon de développer un peu ce point. A cause des déboires rencontrés
avec les langages procéduraux, il est louable qu'une équipe veuille avancer avec précautions et
comprendre tous les détails avant de passer à la conception et l'implémentation. Il est certain que
lors de la création d'une base de données, il est capital de comprendre à fond les besoins du
client. Mais la conception d'une base de données fait partie d'une classe de problèmes bien définie
et bien comprise ; dans ce genre de programmes, la structure de la base de données
est le problème à résoudre. Les problèmes traités dans ce chapitre font partie de la
classe de problèmes « joker » (invention personnelle), dans laquelle la solution n'est pas une
simple reformulation d'une solution déjà éprouvée de nombreuses fois, mais implique un ou plusieurs
« facteurs joker » - des éléments pour lesquels il n'existe aucune solution préétablie
connue, et qui nécessitent de pousser les recherches [9].
Tenter d'analyser à fond un problème joker avant de passer à la conception et l'implémentation mène
à la paralysie analytique parce qu'on ne dispose pas d'assez d'informations pour résoudre ce type
de problèmes durant la phase d'analyse. Résoudre ce genre de problèmes requiert de répéter le cycle
complet, et cela demande de prendre certains risques (ce qui est sensé, car on essaie de faire
quelque chose de nouveau et les revenus potentiels en sont plus élevés). On pourrait croire que le
risque est augmenté par cette ruée vers une première implémentation, mais elle peut réduire le
risque dans un projet joker car on peut tout de suite se rendre compte si telle approche du
problème est viable ou non. Le développement d'un produit s'apparente à de la gestion de
risque.
|
|
|
|
It’s often proposed that you
“build one to throw away.” With OOP, you may still throw part
of it away, but because code is encapsulated into classes, during the first pass
you will inevitably produce some useful class designs and develop some
worthwhile ideas about the system design that do not need to be thrown away.
Thus, the first rapid pass at a problem not only produces critical information
for the next analysis, design, and implementation pass, it also creates a code
foundation.
|
|
Souvent cela se traduit par « construire un prototype qu'il va falloir
jeter ». Avec la POO, on peut encore avoir à en jeter une partie, mais comme le code
est encapsulé dans des classes, on aura inévitablement produit durant la première passe quelques
classes qui valent la peine d'être conservées et développé des idées sur la conception du système.
Ainsi, une première passe rapide sur un problème non seulement fournit des informations critiques
pour la prochaine passe d'analyse, de conception et d'implémentation, mais elle produit aussi une
base du code.
|
|
|
|
That said, if you’re looking at a
methodology that contains tremendous detail and suggests many steps and
documents, it’s still difficult to know when to stop. Keep in mind what
you’re trying to discover:
|
|
Ceci dit, si on cherche une méthode qui contient de nombreux détails et suggère de
nombreuses étapes et documents, il est toujours difficile de savoir où s'arrêter. Il faut garder à
l'esprit ce qu'on essaye de découvrir :
|
|
|
|
- What are the objects? (How
do you partition your project into its component
parts?)
- What are
their interfaces? (What messages do you need to send to each
object?)
|
|
- Quels sont les objets ? (Comment partitionner le projet en ses
composants élémentaires ?)
- Quelles en sont leur interface ? (Quels sont les messages qu'on a
besoin d'envoyer à chaque objet ?)
|
|
|
|
If you come up with
nothing more than the objects and their interfaces, then you can write a
program. For various reasons you might need more descriptions and documents than
this, but you can’t get away with any less.
|
|
Si on arrive à trouver quels sont les objets et leur interface, alors on
peut commencer à coder. On pourra avoir besoin d'autres descriptions et documents, mais on ne peut
pas faire avec moins que ça.
|
|
|
|
The process can be undertaken in five
phases, and a Phase 0 that is just the initial commitment to using some kind of
structure.
|
|
Le développement peut être décomposé en cinq phases, et une Phase 0 qui est
juste l'engagement initial à respecter une structure de base.
|
|
|
|
Phase 0: Make a plan
|
|
Phase 0 : Faire un plan
|
|
|
|
You must first decide what steps
you’re going to have in your process. It sounds simple (in fact,
all of this sounds simple), and yet people often don’t make this
decision before they start coding. If your plan is “let’s jump in
and start coding,” fine. (Sometimes that’s appropriate when you have
a well-understood problem.) At least agree that this is the
plan.
|
|
Il faut d'abord décider quelles étapes on va suivre dans le développement.
Cela semble simple (en fait, tout semble simple), et malgré tout les gens ne prennent
cette décision qu'après avoir commencé à coder. Si le plan se résume à « retroussons nos
manches et codons », alors ça ne pose pas de problèmes (quelquefois c'est une approche valable
quand on a affaire à un problème bien connu). Mais il faut néanmoins accepter que c'est
le plan.
|
|
|
|
You might also decide at this phase that
some additional process structure is necessary, but not the whole nine yards.
Understandably, some programmers like to work in “vacation mode,” in
which no structure is imposed on the process of developing their work; “It
will be done when it’s done.” This can be appealing for a while, but
I’ve found that having a few milestones along the way helps to focus and
galvanize your efforts around those milestones instead of being stuck with the
single goal of “finish the project.” In addition, it divides the
project into more bite-sized pieces and makes it seem less threatening (plus the
milestones offer more opportunities for celebration).
|
|
On peut aussi décider dans cette phase qu'une structure additionnelle est
nécessaire. Certains programmeurs aiment travailler en « mode vacances », sans structure
imposée sur le processus de développement de leur travail : « Ce sera fait lorsque ce
sera fait ». Cela peut être séduisant un moment, mais disposer de quelques jalons aide à se
concentrer et focalise les efforts sur ces jalons au lieu d'être obnubilé par le but unique de
« finir le projet ». De plus, cela divise le projet en parties plus petites, ce qui le
rend moins redoutable (sans compter que les jalons offrent des opportunités de fête).
|
|
|
|
When I began to study story structure (so
that I will someday write a novel) I was initially resistant to the idea of
structure, feeling that I wrote best when I simply let it flow onto the page.
But I later realized that when I write about computers the structure is clear
enough to me that I don’t have to think about it very much. But I still
structure my work, albeit only semi-consciously in my head. Even if you think
that your plan is to just start coding, you still somehow go through the
subsequent phases while asking and answering certain
questions.
|
|
Quand j'ai commencé à étudier la structure des histoires (afin de pouvoir
un jour écrire un roman), j'étais réticent au début à l'idée de structure, trouvant que j'écrivais
mieux quand je laissais juste la plume courir sur le papier. Mais j'ai réalisé plus tard que quand
j'écris à propos des ordinateurs, la structure est suffisamment claire pour moi pour que je n'ai
pas besoin de trop y réfléchir. Mais je structure tout de même mon travail, bien que ce soit
inconsciemment dans ma tête. Même si on pense que le plan est juste de commencer à coder, on passe
tout de même par les phases successives en se posant certaines questions et en y
répondant.
|
|
|
|
The mission statement
|
|
L'exposé de la mission
|
|
|
|
Any system you build, no matter how
complicated, has a fundamental purpose; the business that it’s in, the
basic need that it satisfies. If you can look past the user interface, the
hardware- or system-specific details, the coding algorithms and the efficiency
problems, you will eventually find the core of its being—simple and
straightforward. Like the so-called
high concept from a
Hollywood movie, you can describe it in one or two sentences. This pure
description is the starting point.
|
|
Tout système qu'on construit, quelle que soit sa complexité, a un but, un
besoin fondamental qu'il satisfait. Si on peut voir au delà de l'interface utilisateur, des détails
spécifiques au matériel - ou au système -, des algorithmes de codage et des problèmes d'efficacité,
on arrive finalement au coeur du problème - simple et nu. Comme le soi-disant concept
fondamental d'un film hollywoodien, on peut le décrire en une ou deux phrases. Cette
description pure est le point de départ.
|
|
|
|
The high concept is quite important
because it sets the tone for your project; it’s a mission statement. You
won’t necessarily get it right the first time (you may be in a later phase
of the project before it becomes completely clear), but keep trying until it
feels right. For example, in an air-traffic control system you may start out
with a high concept focused on the system that you’re building: “The
tower program keeps track of the aircraft.” But consider what happens when
you shrink the system to a very small airfield; perhaps there’s only a
human controller, or none at all. A more useful model won’t concern the
solution you’re creating as much as it describes the problem:
“Aircraft arrive, unload, service and reload, then
depart.”
|
|
Le concept fondamental est assez important car il donne le ton du
projet ; c'est l'exposé de la mission. Ce ne sera pas nécessairement le premier jet qui sera
le bon (on peut être dans une phase ultérieure du projet avant qu'il ne soit complètement clair),
mais il faut continuer d'essayer jusqu'à ce que ça sonne bien. Par exemple, dans un système de
contrôle de trafic aérien, on peut commencer avec un concept fondamental basé sur le système qu'on
construit : « Le programme tour de contrôle garde la trace d'un avion ». Mais cela
n'est plus valable quand le système se réduit à un petit aérodrome, avec un seul contrôleur, ou
même aucun. Un modèle plus utile ne décrira pas tant la solution qu'on crée que le problème :
« Des avions arrivent, déchargent, partent en révision, rechargent et
repartent ».
|
|
|
|
Phase 1: What are we making?
|
|
Phase 1 : Que construit-on ?
|
|
|
|
In the previous generation of program
design (called procedural design), this is called “creating the
requirements analysis and
system
specification.” These, of course, were places to get lost;
intimidatingly named documents that could become big projects in their own
right. Their intention was good, however. The requirements analysis says
“Make a list of the guidelines we will use to know when the job is done
and the customer is satisfied.” The system specification says
“Here’s a description of what the program will do (not
how) to satisfy the requirements.” The requirements analysis is
really a contract between you and the customer (even if the customer works
within your company, or is some other object or system). The system
specification is a top-level exploration into the problem and in some sense a
discovery of whether it can be done and how long it will take. Since both of
these will require consensus among people (and because they will usually change
over time), I think it’s best to keep them as bare as
possible—ideally, to lists and basic diagrams—to save time. You
might have other constraints that require you to expand them into bigger
documents, but by keeping the initial document small and concise, it can be
created in a few sessions of group brainstorming with a leader who dynamically
creates the description. This not only solicits input from everyone, it also
fosters initial buy-in and agreement by everyone on the team. Perhaps most
importantly, it can kick off a project with a lot of
enthusiasm.
|
|
Dans la génération précédente de conception de programmes (conception
procédurale), cela s'appelait « l'analyse des besoins et
les spécifications du système ». C'étaient des endroits où on se perdait facilement,
avec des documents au nom intimidant qui pouvaient occulter le projet. Leurs intentions
étaient bonnes, pourtant. L'analyse des besoins consiste à « faire une liste des indicateurs
qu'on utilisera pour savoir quand le travail sera terminé et le client satisfait ». Les
spécifications du système consistent en « une description de ce que le programme fera (sans ce
préoccuper du comment) pour satisfaire les besoins ». L'analyse des besoins est un
contrat entre le développeur et le client (même si le client travaille dans la même entreprise, ou
se trouve être un objet ou un autre système). Les spécifications du système sont une exploration
générale du problème, et en un sens permettent de savoir s'il peut être résolu et en combien de
temps. Comme ils requièrent des consensus entre les intervenants sur le projet (et parce qu'ils
changent au cours du temps), il vaut mieux les garder aussi bruts que possible - idéalement
en tant que listes et diagrammes - pour ne pas perdre de temps. Il peut y avoir d'autres
contraintes qui demandent de produire de gros documents, mais en gardant les documents initiaux
petits et concis, cela permet de les créer en quelques sessions de brainstorming avec un leader qui
affine la description dynamiquement. Cela permet d'impliquer tous les acteurs du projet, et
encourage la participation de toute l'équipe. Plus important encore, cela permet de lancer un
projet dans l'enthousiasme.
|
|
|
|
It’s necessary to stay focused on
the heart of what you’re trying to accomplish in this phase: determine
what the system is supposed to do. The most valuable tool for this is a
collection of what are called “use cases.”
Use cases identify key features in the system that will reveal some of the
fundamental classes you’ll be using. These are essentially descriptive
answers to questions
like[10]:
- “Who will use this
system?”
- “What can
those actors do with the system?”
- “How does
this actor do that with this
system?”
- “How
else might this work if someone else were doing this, or if the same actor had a
different objective?” (to reveal
variations)
- “What
problems might happen while doing this with the system?” (to reveal
exceptions)
|
|
Il est nécessaire de rester concentré sur ce qu'on essaye d'accomplir dans
cette phase : déterminer ce que le système est supposé faire. L'outil le plus utile pour cela
est une collection de ce qu'on appelle « cas d'utilisation ». Les cas d'utilisation
identifient les caractéristiques clefs du système qui vont révéler certaines des classes
fondamentales qu'on utilisera. Ce sont essentiellement des réponses descriptives à des questions
comme[10] :
- « Qui utilisera le système ? »
- « Que peuvent faire ces personnes avec le système
? »
- « Comment tel acteur fait-il cela avec le
système ? »
- « Comment cela pourrait-il fonctionner si quelqu'un d'autre faisait
cela, ou si le même acteur avait un objectif différent ? » (pour trouver les
variations)
- « Quels problèmes peuvent apparaître quand on fait cela avec le
système ? » (pour trouver les exceptions)
|
|
|
|
If you are
designing an auto-teller, for example, the use case for a particular aspect of
the functionality of the system is able to describe what the auto-teller does in
every possible situation. Each of these “situations” is referred to
as a scenario, and a use case can be considered a
collection of scenarios. You can think of a scenario as a question that starts
with: “What does the system do if...?” For example, “What does
the auto-teller do if a customer has just deposited a check within the last 24
hours, and there’s not enough in the account without the check having
cleared to provide a desired withdrawal?”
|
|
Si on conçoit un guichet automatique, par exemple, le cas d'utilisation
pour un aspect particulier des fonctionnalités du système est capable de décrire ce que le guichet
fait dans chaque situation possible. Chacune de ces situations est appelée
un scénario, et un cas d'utilisation peut être considéré comme une collection de
scénarios. On peut penser à un scénario comme à une question qui commence par « Qu'est-ce que
le système fait si... ? ». Par exemple, « Qu'est que le guichet fait si un client
vient de déposer un chèque dans les dernières 24 heures, et qu'il n'y a pas assez dans le compte
sans que le chèque soit encaissé pour fournir le retrait demandé ? ».
|
|
|
|
Use case diagrams
are intentionally simple to prevent you from getting bogged down in system
implementation details prematurely:
|
|
Les diagrammes de cas d'utilisations sont voulus simples pour ne pas se
perdre prématurément dans les détails de l'implémentation du système :
|
|
|
|
|
|
|
|
|
|
Each stick person represents an
“actor,” which is typically a human or some
other kind of free agent. (These can even be other computer systems, as is the
case with “ATM.”) The box represents the boundary of your system.
The ellipses represent the use cases, which are descriptions of valuable work
that can be performed with the system. The lines between the actors and the use
cases represent the interactions.
|
|
Chaque bonhomme représente un « acteur », typiquement une personne ou
une autre sorte d'agent (cela peut même être un autre système informatique, comme c'est le cas avec
« ATM »). La boîte représente les limites du système. Les ellipses représentent les cas
d'utilisation, qui sont les descriptions des actions qui peuvent être réalisées avec le système.
Les lignes entre les acteurs et les cas d'utilisation représentent les interactions.
|
|
|
|
It doesn’t matter how the system is
actually implemented, as long as it looks like this to the
user.
|
|
Tant que le système est perçu ainsi par l'utilisateur, son implémentation
n'est pas importante.
|
|
|
|
A use case does not need to be terribly
complex, even if the underlying system is complex. It is only intended to show
the system as it appears to the user. For example:
|
|
Un cas d'utilisation n'a pas besoin d'être complexe, même si le système
sous-jacent l'est. Il est seulement destiné à montrer le système tel qu'il apparaît à
l'utilisateur. Par exemple :
|
|
|
|
|
|
|
|
|
|
The use cases produce the requirements
specifications by determining all the interactions that the user may have with
the system. You try to discover a full set of use cases for your system, and
once you’ve done that you have the core of what the system is supposed to
do. The nice thing about focusing on use cases is that they always bring you
back to the essentials and keep you from drifting off into issues that
aren’t critical for getting the job done. That is, if you have a full set
of use cases, you can describe your system and move onto the next phase. You
probably won’t get it all figured out perfectly on the first try, but
that’s OK. Everything will reveal itself in time, and if you demand a
perfect system specification at this point you’ll get
stuck.
|
|
Les cas d'utilisation produisent les spécifications des besoins en
déterminant toutes les interactions que l'utilisateur peut avoir avec le système. Il faut trouver
un ensemble complet de cas d'utilisations du système, et cela terminé on se retrouve avec le coeur
de ce que le système est censé faire. La beauté des cas d'utilisation est qu'ils ramènent toujours
aux points essentiels et empêchent de se disperser dans des discussions non essentielles à la
réalisation du travail à faire. Autrement dit, si on dispose d'un ensemble complet de cas
d'utilisation, on peut décrire le système et passer à la phase suivante. Tout ne sera pas
parfaitement clair dès le premier jet, mais ça ne fait rien. Tout se décantera avec le temps, et si
on cherche à obtenir des spécifications du système parfaites à ce point on se retrouvera
coincé.
|
|
|
|
If you do get stuck, you can kick-start
this phase by using a rough approximation tool: describe the system in a few
paragraphs and then look for nouns and verbs. The nouns can suggest actors,
context of the use case (e.g., “lobby”), or artifacts manipulated in
the use case. Verbs can suggest interactions between actors and use cases, and
specify steps within the use case. You’ll also discover that nouns and
verbs produce objects and messages during the design phase (and note that use
cases describe interactions between subsystems, so the “noun and
verb” technique can be used only as a brainstorming tool as it does not
generate use cases)
[11].
|
|
Si on est bloqué, on peut lancer cette phase en utilisant un outil
d'approximation grossier : décrire le système en quelques paragraphes et chercher les noms et
les verbes. Les noms suggèrent les acteurs, le contexte des cas d'utilisation ou les objets
manipulés dans les cas d'utilisation. Les verbes suggèrent les interactions entre les acteurs et
les cas d'utilisation, et spécifient les étapes à l'intérieur des cas d'utilisation. On verra aussi
que les noms et les verbes produisent des objets et des messages durant la phase de design (on peut
noter que les cas d'utilisation décrivent les interactions entre les sous-systèmes, donc la
technique « des noms et des verbes » ne peut être utilisée qu'en tant qu'outil de
brainstorming car il ne fournit pas les cas d'utilisation) [11].
|
|
|
|
|
|
|
|
|
|
|
|
|
