Processus

1
Processus Modéliser

• Capt M. Quintin

2
Sujet de cette section

• Cycle de vie
• Activités dingénieries
• OOA OOD
• Modéliser
• Processus de développement Itératif
• Modéliser Documenter

3
(No Transcript)
4
Activités et tâches dingénieries

• Définition des Besoins
• Comportement du système
• tâche Modéliser
• Analyser (OOA)
• Domaine (Problème)
• tâche Modéliser
• Concevoir (OOD)
• Solution
• tâche Modéliser

Interdépendantdonc se doit dêtre itératif.
5
Tâches

• Requirements Definition
• Clarifies the problem to be solved.
• Provides the basic charter for the systems
  functions.
• Domain Analysis
• Is the process of defining a precise model that
  represents the problem domain.
• Provides de key logical structure of the system.
• Design
• uses the results of analysis and produces an
  effective, efficient implementation of the
  domain.
• Provides the key physical structure of the
  system, maps the logical structure to it, and
  leads to implementation.

6
Définir les besoins

• Requirements are capabilities and conditions to
  which the system (and more broadly, the project)
  must conform.
• A prime challenge of requirements work is to
  find, communicate, and remember (document) what
  is really needed, in a form that clearly speaks
  to the client and development team members.

7
Analyser

• Domain
• Finding and describing the objects, or concepts,
  in the problem domain.
• In conjunction with design
• Defining software objects and how they
  collaborate to fulfill the requirements

8
Concevoir

• Defining software objects and (choosing) how they
  collaborate to fulfill the requirements.
• Make choice about structure
• Pattern implementation
• Architecture style
• The design defines how to solve the problem, what
  to program.

9
Analysis vs Design

• Analysis
• what?
• understanding the domain problem
• artifacts
• domain model
• class diagram
• interaction diag
• constraints
• vocabulary

• Design
• how?
• decision to solve the problem.
• artifacts
• design model
• class diagram
• interaction diagram
• patterns
• architecture
• UI

10
Terminology Wars
More analysis oriented
More design oriented

• Terms not fixed, but used along a continuum.
• Within the same hours of mental work, the
  developer may go back and forth between analysis
  and design activities.

11
Modeling

• Capturing the requirements
• Capturing the problem
• Capturing the design in ways that are easy to
  communicate, to review, to implement, and to
  evolve

It is what the second part of this course is
about.
12
Implémentation

• The coding, which will be realized during
  implementation, can hardly be better than the
  design artifacts that are produced by the
  analysis and design activities.
• Testing only allows to assess product quality.
  The quality of OOA/D will determine the product
  quality.

13
Sujet de cette section

• Cycle de vie
• Activités dingénieries
• OOA OOD
• Modéliser
• Processus de développement Itératif
• Modéliser Documenter

14
(No Transcript)
15
Development Process

• In which sequence engineering activities or task
  have to be performed in?
• pas nécessairement linéaire mais plutôt itératif.

16
Development Process

• Model of Software development Process is about
• Try to model into a specific process how to
  sequence engineering activities in order to
  develop software.
• Try to identify the key engineering activities in
  the development of software and their
  relationships to one another.

17
Développement itérativePourquoi?

• Cest le processus naturel du cerveau humain de
  fonctionner lorsquil doit faire preuve de
  créativité.
• exemple écrire un livre
• Implique implicitement le pouvoir de sadapter
  aux changements qui sont inévitables.
• À ne pas confondre avec un processus
  non-contrôler ou réactive.

18
Développement Itérative

• Avantage
• Early risks mitigation
• Early feedback, led to a refined system that mets
  real user requirements.
• Manager task complexity (not overwhelmed by
  analysis paralysis or very long complex steps.

19
Itérative development

• Key items
• Small step
• Rapid feedback
• Adaptation.

20
Methodology/Method vs Process Model

• Process Models key activities and their
  relationships
• Methodology prescribs when, what, who, and
  precisely how some tasks have to be performed.
  Methodology are specific implementation of a
  process model.

21
Development Process

• There are different software development process
  models and methods that propose different
  sequences of engineering activities
• Waterfall Model
• Prototyping (not a process)
• Incremental
• Spiral
• Rational Unified Process (RUP)
• Rapid Application Development (RAD)
• Agile Development
• XP, Scrum, Crystal, Feature Driven, Adaptive
• Etc.

22
Development Process

• Sans étudier les processus, ce qui est le sujet
  dun autre cours, nous aller référer au processus
  Unified Process (UP), pour pouvoir mettre en
  perspective les différentes activités
  dingénieries dans le contexte du développement
  des logiciels.

23
Quest-ce quun processus?

• Un processus est un ensemble d'activités
  structurés, destiné a accomplir un certain but.
• Un processus utile devrait vous permettre de
  répondre aux questions suivantes
• Où sommes-nous?
• Comment avons-nous fait pour nous rendre à ce
  point?
• Où allons-nous ensuite
• Quand pouvons-nous dire que nous sommes terminés?

24
Processus micro

• Identifier les Besoins
• Analyser
• Identifier élément du modèle à niveau
  dabstraction donné
• Identifier les responsabilités cet élément
• Identifier les relations parmi les éléments
• Concevoir
• Choisir une structure (patterns, architecture)
• Implémenter
• Définir linterface et ensuite limplémentation
  de chaque élément

Les éléments du modèle sont classe, module,
objet, acteur, cas dutilisation , etc..
25
Graphique macro/micro
Inception
Elaboration
Construction
Transition
26
Charge de travail
27
Processus macro

• Inception
• Établir la porté, faisabilité et la viabilité
• Élaboration
• Analyse du domaine, conception de larchitecture.
• Construction
• Évolution de limplémentation
• Transition
• Optimisation de la performance.

28
Inception

• But
• Établir le coût approximatif et les avantages du
  système.
• Établir une vision pour système et valider ses
  assomptions.
• Analyse initial pour obtenir la portée du projet.
  
• Produits
• business case
• Diagrammes de cas dutilisation initial

29
ÉlaborationAnalyse du domaine

• But
• Fournir une description du problème
• Élaboration fondée sur le comportement et non la
  forme
• Pas une compréhension approfondie du comportement
  du système.
• Produits
• Diagrammes dutilisation
• Diagrammes d'interaction pour dénoter chaque cas
  d'utilisation
• Diagrammes de classes pour montrer les relations
  statiques entre les objet.
• Spécifications de classes initiales

30
Élaboration Architecture et planification

• but
• Créer une architecture pour aider lévolution et
  modification du système
• Établir des politique communes qui sont utilisées
  de façon uniforme a travers tout le système.
• mécanisme local qui apparaît dans tout système
  (par exemple détection et manipulation derreurs,
  gestion de la mémoire, gestion du stockage des
  données, lapproche au contrôle, les tactiques du
  domaine spécifique, etc...)
• Produits
• Diagrammes de classes et paquets
• Relâche dun prototype exécutable.
• Plan de relâche exécutable

31
Construction

• But
• développer et implémenter la solution par
  l'amélioration itérative, menant finalement à la
  réalisation du système
• Produits
• Une suite de versions exécutables représentant
  l'amélioration successive à la version
  architecturale initiale.
• Une nouvelle version a toutes les 6-8 semaines,
  selon la complexité.
• Prototype de comportement
• Évolution de la documentation du système

32
Transition

• But
• Aucun nouveau développement pour ajouter de la
  fonctionnalité
• Compléter lélimination des bugs
• Optimisation et ajustement du produit
• Produits
• Maintenance de la documentation danalyse et
  dimplémentation

33
Charge de travail
34
Maintenance

• But
• Gestion des activités après la livraison
• Semblable a la phase de construction sauf
• Architecturale est moins un issue
• Des changements localisés sont faits au fur et a
  mesure que de nouvelles conditions sont ajoutées
  et les bug (anomalies) sont fixés
• Produits
• Similaire a la construction

35
(No Transcript)
36
Activités et tâches dingénieries

• Définition des Besoins
• Comportement du système
• tâche Modéliser
• Analyser (OOA)
• Domaine (Problème)
• tâche Modéliser
• Concevoir (OOD)
• Solution
• tâche Modéliser
• Implémenter
• tâche tester coder

Itératif
37
Itératif

• Applique le processus micro d une façon
  répétitive
• Prédominant durant la phase d élaboration et
  construction.

38
Development Life cycle
39
Itération Model-Driven Development
Identifier besoins
Modelizer Documenter
Tester coder
implementer
analyser
concevoir
Modelizer Documenter
Modelizer Documenter
40
Sujet de cette section

• Cycle de vie
• Activités dingénieries
• OOA OOD
• Modéliser
• Processus de développement Itératif
• Modéliser Documenter

41
Modéliser

• Pourquoi
• Comprendre (understanding)
• Communiquer
• Langage the only tools for thinking.
• Model Most prowerfull mean in understanding and
  communicating your work.
• Fait partie intégrale de OOA/D.
• Model est composé de
• Diagramme (UML)
• Spécification (plain english text)

42
Model Communication
is
43
Modelé (modeling)

• Modelé consiste à créer une simplification de la
  réalité. Cela nous aide à mieux comprendre cette
  réalité.
• UML est un langage qui nous permet dillustrer
  des models à partir délément de base classes,
  interfaces, relations, etc.
• Les Diagrammes nous permettent de visualisé ces
  éléments
• Différents diagrammes nous donnent différentes
  vues.

44
Différent niveau dabstraction

• Les analystes et concepteurs travaillent à des
  niveau dabstraction plus élevé que les
  programmeurs qui travaillent à un bas niveau
  dabstraction.
• Tous ont besoins de travaillé à partir dun même
  model pour arrivé à construire le système
  désiré, par contre ils travaille avec des
  différents diagrammes qui illustrent différent
  niveaux dabstraction.

45
Différent niveaux dabstraction

• Deux façon de créer des diagrammes qui illustrent
  différent niveaux dabstraction du même model
• diagrammes avec différent niveaux de détail
• différents diagrammes avec différent niveaux
  dabstraction avec une correspondance entre les
  différent niveaux.

46
Usage des Diagrammes

• Trois perspectives dusage des diagrammes en
  fonction du contexte
• Conceptuelle (analyste)
• model du domaine
• De spécification (concepteurs)
• model de la conception (forward-engineering)
• Dimplémentation (programmeurs)
• model de limplémentation (reverse-engineering)
• ces différents rôles sont plus souvent
  quautrement réalisé par les mêmes personnes,
  mais à différent moment du développement du
  produit.

47
Perspective conceptuelle

• Permet de mettre en perspective les différents
  concepts dans le domaine du problème.
• Décrie le problème à travers des classes et leurs
  relations entre elles.
• Les concepts peuvent directement correspondre à
  des classes de la perspective dimplémentation,
  mais pas nécessairement.

48
Perspective de spécification

• Une vue abstraites de la conception du logiciel.
• illustre une architecture de classe.
• Concentration sur les interfaces.
• Définition de type.
• Type et interface sont similaires
• interface versus interface Java

49
Perspective dimplémentation

• Une vue qui décrit le secret de chacune des
  classes.
• Les structures de données devient visible a ce
  point.
• Les classes sont définies
• état et comportement
• secret et interface

50
Model Documentation
51
(No Transcript)
52
Activités et tâches dingénieries

• Définition des Besoins
• Comportement du système
• tâche Modéliser
• Analyser (OOA)
• Domaine (Problème)
• tâche Modéliser
• Concevoir (OOD)
• Solution
• tâche Modéliser
• Implémenter
• tâche tester coder

Itératif
53
Modélisation Itératif

• Use-case
• scénario
• Class Diag
• Into javadoc
• CRC
• Into javadoc
• Séquence Diag
• scénario
• Transition Diag

54
(No Transcript)
55
Model-Driven Development
List all models
Once language was key - Now its design.
56
Modeling workflow
List steps
57
In this case, no distinction between analysis and
design.
58
(No Transcript)
59
Documentation

• Compromit une question de jugement qui vient
  avec lexpérience.
• Quantité minimal
• Qualité Très bonne sans être parfaite.
• Perfection perte de temps, deffort et de
  ressource.
• Tendance
• petit projet
• ressource limitée
• Manque de documentation
• gros projet
• problème de communication
• Trop de lien de communication a maintenir
• Trop de documentation

60
Documentation

• Depending on need, scale both up and down in
  terms of sophistication and formality.

61
Evolution of the artifact sets throughout project
life-cyle
62
Documentation

• The point of an artifact is not the document or
  diagram itself, but the thinking, analysis, and
  proactive readiness (and then its recording, to
  avoid re-invention or having to repeat things
  verbally).
•  In preparing for battle, I have always found
  the plans are useless, but planning
  indispensable 
• "The map is not the terrain.
•  The information is not the same as the reality
  it describes  .

63
Documentation

• If the product of your analysis design is not
  on paper than your work is very speculative and
  more likely flaulty (which differs from
  incomplete).
• No one would be able to review it, not even
  yourself.
• Even for a personal project, thing on paper (i.e.
  document).

64
Processus Personnel ItératifArtifacts

• Modélise (document)
• Définir les besoins
• Analyse
• Design
• Implémente
• Testing
• Coding
• optimizing
• Acceptance Test
• Deploy

65
Sujet de cette section

• Cycle de vie
• Activités dingénieries
• OOA OOD
• Modéliser
• Processus de développement Itératif
• Modéliser Documenter

66
Incréments Architecture

• À présenté seulement après la section Analyse
  Conception.

67
Développement par Incrément

• Pour chacune des itérations de développement,
  produire une  release  qui peut être démontré
  au client.
• Chacune des  releases  est un incrément
  démontrant des fonctionnalités additionnelles
  (cas d utilisations).

68
Planification

• Un plan nous permet de compléter limplémentation
  avec une série d'itérations (versions
  exécutables)
• Le plan assigne chaque cas dutilisation à une
  itération, ensuite la séquence des itérations à
  suivre peut être déterminée, ainsi quune date de
  début pour chaque itération

69
Itération gt incrément (release)
70
Plan de versions exécutables

• Assigne les cas dutilisation selon
• la priorité spécifiée par l'utilisateur
• Le risque architectural, dhoraire ou
  dimplémentation
• traiter les items à gros risques en premier
• L'effort nécessaire
• version de grandeur semblable et raisonnable
• séparer les cas dutilisation trop grand

71
Other planning data

• Classes to be implemented
• Inputs
• you may have to provide drivers
• Output
• you may have to provide stubs
• ASIDE A good rule of thumb is that you will
  produce as much test harness as production code

72
Version Exécutable pointage Goal Vérification
et usage des éléments utilisés pour le traitement
de tous les pointages dune compétition. Start
Date 28 Mar 01 Effort 12 développeur-semaines C
lasses a être implémenter Compétition,
Évènement, Essai, Gymnaste, Équipe Cas
dutilisation a être implémenter Publication des
résultats entrées Une base de donnée simulée
avec tous les évènements et essais pour une
compétition dune rencontre qui va générer le
rapport attendu. sorties Le rapport démontrer
lors de la discussion des besoins
73
Architecture en premier!

• Il est primordial que dès le début, lors du
  design (élaboration), quon établit une
  architecture.
• Architecture est, entre autre, une structure qui
  permet de mieux gérer la complexité
  (décomposition).
• Une architecture permet aussi de mieux
  supporter/maintenir la fonctionnalité du produit.

74
Résumé Processus de développement

• Processus itérative de développement.
• Développement en incrément.
• Architecture en premier.