Définition

Un langage de modélisation est un langage utilisé pour modéliser de nouveaux logiciels ou systèmes. Les deux types de modélisation existants sont la modélisation graphique et la modélisation textuelle. La première, comme son nom le suggère, a pour outils principaux des diagrammes, des symboles, des flèches pour une représentation visuelle. Le second, comme son nom l’indique également, est basé sur des instructions textuelles ayant pour ambition de définir le système dans son ensemble.

L’émergence des langages graphiques et de l’UML

Parmi les deux grands types de modélisation, le langage graphique est celui connaissant de loin l’essor le plus important, en particulier à travers l’émergence de l’UML (Unified modeling language). Ce type de langage est plus visuel et ainsi plus facile d’utilisation au premier abord. Il permet également d’avoir une vue d’ensemble assez facilement et permet ainsi de mettre en lumière les informations essentielles.

L’UML s’est très fortement popularisé au cours des dernières années. Ce langage de modélisation standardisé permet aux développeurs de spécifier, visualiser, construire et documenter les artefacts d’un logiciel. Il est notamment très utilisé dans la programmation objet-orientée. Sa force est l’utilisation de notation graphique ergonomique permettant de créer des modèles visuels des logiciels. Il existe néanmoins nombre d’autres langage de modélisation graphique comme Flowchart, Drakon ou AADL pour ne citer qu’eux.

Un langage textuel en perte de vitesse mais encore d’actualité

Si les dernières années ont vu la popularité des langages graphiques monté en flèche, les langages textuels ne sont pas tombé en désuétude pour autant et conservent certains atouts indéniables. Beaucoup de DSL (domain specific language), largement utilisés aujourd’hui, sont ainsi textuels. Cela s’explique par le fait que le langage graphique peut devenir illisible en cas de surcharge d’informations. Le texte permet de garder une certaine structure dans cette situation. Par ailleurs, beaucoup de structures graphiques sont accompagnés d’ajouts textuels afin d’apporter des clarifications impossibles ou compliquées à représenter graphiquement. Une structure textuelle est également plus simple à réaliser en termes de conception car plus linéaire et moins ambigüe.

Mon analyse: Langage graphique ou textuel ?

En synthèse, il apparaît que ces deux modèles sont extrêmement complémentaires. Plutôt que de les opposer, il apparaît plus pertinent de les combiner. En effet, un langage de modélisation graphique présente des avantages que le texte ne saurait transcrire: il permet d’avoir une vue d’ensemble rapide, et permet de mieux se représenter visuellement le contenu. Ainsi, le langage graphique me paraît plus adapté à la représentation de macro-informations, permettant de synthétiser les points essentiels du logiciel. En revanche, la représentation graphique touche ses limites au moment de représenter des informations plus détaillées et complexes. Un graphique surchargé peut rapidement devenir confus et même amener à des interprétations erronées. De plus, il n’est pas forcément adapté à la représentation d’informations nécessitant des explications détaillées. Pour modéliser au mieux ce type d’information complexes et détaillées, le texte m’apparaît ainsi plus pertinent. Malgré ses défaillances en termes de visuel, le texte permet de représenter de manière concise et non-ambigüe des informations parfois difficiles à appréhender au premier abord.

Finalement, ces deux modèles me paraissent totalement complémentaires puisque les avantages de l’un complètent les faiblesses de l’autre et inversement.

Définition

Un Use-Case est une série d’étapes à suivre par un acteur donné sur un système donné, afin d’atteindre un objectif. En d’autres termes, c’est une série d’instructions données à cet acteur particulier afin de réaliser une action sur un système. Il est important de préciser que cet acteur n’est pas nécessairement un humain. Il peut également s’agir d’un système externe par exemple. Ce faisant, un il fait le lien entre le système et le monde extérieur. Les Use-Cases permettent également d’avoir une vue d’ensemble des composants du système ou encore des différents roles de ses utilisateurs, ainsi que des réponses à leurs besoins.

Mettre en place un Use Case

Avant de mettre en place l’Use Case lui-même, il est primordial de bien définir l’environnement dans lequel celui-ci va se dérouler. Pour ce faire, plusieurs étapes préambules sont nécessaires.

• L’objectif du Use Case doit être définit et explicite.
• Les utilisateurs qui disposeront d’un accès au case doivent également être bien établis.
• Le périmètre du Use Case doit être clarifié
• Quel seront les étapes parcourues lors de ce use case, définition du “workflow”

En synthèse, il est très important d’avoir une vue d’ensemble des objectifs, acteurs et systèmes impliqués dans la réalisation du Use Case avant de démarrer ce dernier.

Le Use Case en lui-même consiste en une série d’instructions , plus ou moins détaillées (Le Use Case “concret” étant la forme la plus détaillée et rigide tandis que le Use Case “essentiel” est quant à lui beaucoup plus souple mais également indéterminé). Ces instructions sont données pour un acteur donné sur un système donné. Ce faisant, le Use Case crée une relation triangulaire entre acteurs, système et instructions.

Use Case Diagram

Le Use Case Diagram est de plus en populaire et ne cesse de se développer. Il permet de représenter le Use Case d’une manière plus visuelle et lisible qu’une série d’instructions brutes.

Le Use Case Diagram adopte généralement la forme d’un rectangle avec le nom du système inscrit en haut. Tout ce qui se passe sur le système en lui-même sera inclus dans le rectangle tandis que tous les intervenants extérieurs, quelle que soit leur nature (autres systèmes, humains,…) sont représentés en dehors de ce rectangle. La première chose à placer sur le diagramme sont ainsi les intervenants extérieurs, en dehors du rectangle. On distingue généralement les acteurs extérieurs en deux catégories: les acteurs primaires initiant le système, et les acteurs secondaires agissant en réaction aux réponses du système. Une fois les acteurs extérieurs définis et représentés, il s’agit de représenter dans le rectangle système les différentes actions qui devront être exécutées. Les acteurs sont ensuite reliés aux taches les correspondants à l’aide de segments.

Le diagramme peut être complété et complexifié à l’aide d’information additionnelles comme la nature de la relation entre un acteur et son action. Cette relation peut être d’association, d’inclusion, d’exclusion ou de généralisation.

Le niveau de détail exprimé dans l’User Case dépend à mon sens de la complexité du système et du niveau d’information que l’on souhaite transmettre aux acteurs. Il n’est pas utile de fournir un niveau de détail trop élevé si le diagramme est destiné à des acteurs potentiellement peu à l’aise avec le système alors que ceci peut s’avérer pertinent s’il se destine à des personnes plus qualifiées ayant vocation à rentrer plus en détail dans le fonctionnement du système.

Histoire

Le “Unified Software Process” fut originellement créé par Ivar Jacobson. En 1988, il définit Objectory V1.0, qui constitue la base sur laquelle se développeront ensuite l’RUP et l’EUP. Plusieurs versions améliorées d’Objectory V1.0 seront alors développées jusqu’à la publication par Jacobson en 1999 de The Unified software development process. Ce livre fournit un cadre détaillé de ce qu’est un Unified process. Il y définit également les jalons essentiels à la conduite d’un projet, à savoir l’identification du besoin client, l’analyse, le design, le codage et la phase de test. Plusieurs variantes de l’Unified process seront développées par la suite par diverses acteurs. La plus populaire à ce jour est le Rational Unified Process (RUP), que nous définirons plus en détails dans cet article.

Définition

Contrairement à ce que son nom pourrait laisser suggérer, l’Unified process n’est pas un simple “process”, mais plutôt un cadre de travail modulable en fonction de différents projets ou organisations. En d’autres termes c’est une architecture permettant de cadrer le développement d’un logiciel qui conserve néanmoins une certaine souplesse afin de s’adapter à des contextes diverses.

Cette manière de faire à été développée en réponse à la complexité grandissante des développements de logiciel, qui ne pouvaient plus être mis en oeuvre sans une structure claire et cohérente. Elle fournit ainsi une ligne de conduite aux différents individus et équipes d’un projet.

3 composantes font l’essence d’un Unified Process:

• Il doit être use-case driven, c’est à dire qu’il base son raisonnement sur l’interaction entre le système et l’utilisateur. C’est le besoin de l’utilisateur qui détermine les exigences auxquelles devra répondre le système.
• L’architecture du logiciel est centrale dans son développement. Si les use case déterminent in fine l’architecture du projet, celle-ci permet également de centraliser les besoins et d’offrir par la même une base sur lesquelles les use case s’appuient également. Les notions de use case et d’architecture sont donc intimement liées, les premiers composants la seconde, et celle-ci fournissant un cadre aux premiers.
• Enfin, le projet doit-être itératif , c’est à dire en progression constante. C’est ce qui donne une certaine souplesse à l’architecture définit, et permet au projet de ne pas s’enfermer dans un cadre rigide qui pourrait perdre en pertinence en fonction des nouveaux éléments faisant emergence.

Le développement du RUP

Le RUP, Rational Unified process, a été développé en 2003 par Rational, une branche d’IBM. Ce processus est vite devenu une référence dans le domaine et est encore aujourd’hui fréquemment utilisé.

Le RUP compte quatre phases principales, qui restent constante en dépit de la flexibilité contextuelle a laquelle l’architecture peut être confrontée.

La première phase est la phase d’ “inception”, c’est à dire de démarrage. Elle consiste à cadrer le projet et ses objectifs, afin de pouvoir déterminer les coûts qu’il engendrera, ainsi que les ressources à déployer.

Vient ensuite la phase d’élaboration, au cours de laquelle sera définie l’architecture globale du logiciel. Il s’agit là d’une phase de conception et d’analyse technique qui reste néanmoins assez générale.

La phase de conception qui suit consiste en la mise en oeuvre de l’architecture définie au cours de l’élaboration. C’est une phase de développement du logiciel.

Enfin, la phase de “transition” permet de faire la bascule entre le développement et la mise en production du logiciel. C’est au cours de cette phase que le passage de témoin aux utilisateurs finaux est effectué.

In my understanding, a software development life cycle could be defined as a blueprint followed by a development team in order to perform the development of a software as efficiently as possible.

There is no optimal life cycle in absolute, but several models are popular, such as :

• Waterfall model
• V-shaped model
• Agile model
• Evolutionary model
• Magic-box model.
• Spiral model
• Iterative model

Each has its pros and cons and can be used in different contexts. For instance, in the Waterfall model, the steps occur one by one. It makes the project really easy to follow and understand. Nevertheless, it also makes the project less flexible. During a complex and long-term project, some steps can overlap, and each workstream doesn’t progress necessarily at the same pace. Hence, the waterfall model might appear to be too rigid in such context. An agile model, allowing to go back on previous steps (for instance if the client realizes during the development phase that a requirement is missing) would fit better. In counterpart, this flexibility makes the project less readable, as the budget and the architecture can change at anytime. It can also results tension between the client and the developer.

These models vary above all by their manner of disposing the different steps of a development project. Nevertheless, the essence of those steps remain pretty much the same.

Analysis Phase/Requirements

Any project always start with an analysis phase. It consists in defining the requirements of the project, the goals it aims to reach. At the end of this step, every process participants should have a clear understanding of the requirements and their implementation.

Design

After having defined the requirements, the developers design the architecture of the project. It is a technical phase, involving both developers and other stakeholders and tackling questions as varied as budget, time frames, team load,…

Development

After the designing phase, the project is actually developed.

Testing

This phase consists in testing that the development meets the requirements defined during the analysis phase. Modifications needs to be done for the requirements that are not reached.

Difference between Agile and Waterfall cycle :

• Agile is similar to incremental
• Waterfall is rigid. You have to complete the whole design before starting to code. The problem is that, as a matter of facts, unexpected situation occurs very often.

The test is independent from the code. The code permits to transform an input into an output. The test checks the output is correct. You don’t need to know what’s inside the code to define a test.

Deployment

The deployment phase is when the project becomes effective. The end-users, those who actually are going to use the solution, start to handle it. The tech support team remains involved and provide assistance to the users.

These steps generally remain the same in any project. The model chosen change the way they interact, but doesn’t impact significantly their content.

As a conclusion, the Software Development life cycle is at least as important as the development itself. Some projects can involve many stakeholders, and without a precise plan it is merely impossible to work together and provide a satisfactory situation in such context. I had the opportunities to experience it during my first internship, when I was involved in the implementation of SAP S4Hana in a company counting more than 800 employees. Despite all the technical issues, the main issues we met were related to the management of the project and how making more than a 1000 stakeholders work together.

Be yourself; Everyone else is already taken.

— Oscar Wilde.

This is the first post on my new blog. I’m just getting this new blog going, so stay tuned for more. Subscribe below to get notified when I post new updates.

This is an example post, originally published as part of Blogging University. Enroll in one of our ten programs, and start your blog right.

You’re going to publish a post today. Don’t worry about how your blog looks. Don’t worry if you haven’t given it a name yet, or you’re feeling overwhelmed. Just click the “New Post” button, and tell us why you’re here.

Why do this?

• Because it gives new readers context. What are you about? Why should they read your blog?
• Because it will help you focus you own ideas about your blog and what you’d like to do with it.

The post can be short or long, a personal intro to your life or a bloggy mission statement, a manifesto for the future or a simple outline of your the types of things you hope to publish.

To help you get started, here are a few questions:

• Why are you blogging publicly, rather than keeping a personal journal?
• What topics do you think you’ll write about?
• Who would you love to connect with via your blog?
• If you blog successfully throughout the next year, what would you hope to have accomplished?

You’re not locked into any of this; one of the wonderful things about blogs is how they constantly evolve as we learn, grow, and interact with one another — but it’s good to know where and why you started, and articulating your goals may just give you a few other post ideas.

Can’t think how to get started? Just write the first thing that pops into your head. Anne Lamott, author of a book on writing we love, says that you need to give yourself permission to write a “crappy first draft”. Anne makes a great point — just start writing, and worry about editing it later.

When you’re ready to publish, give your post three to five tags that describe your blog’s focus — writing, photography, fiction, parenting, food, cars, movies, sports, whatever. These tags will help others who care about your topics find you in the Reader. Make sure one of the tags is “zerotohero,” so other new bloggers can find you, too.