2 Softwareengeneering

fun cases(obj: Any) {
when (obj) { int addSomeNums(int x, int y, [int z]) {

1 -> println("One") int sum = x + y;
"Hello" -> println("Greeting") if (z != null) {
is Long -> println("Long") sum += z;
INF 3176: Advanced programming

!is String -> println("Not a string") }
else -> println("Unknown") return sum;
} }
}
back.on('save-Image', function(filepath, filename, data){

console.log(data);
var buffer = new Buffer(data, 'base64');
fs.writeFileSync(path.join(filepath, filename), buffer);
console.log('saved Image');
})
techniques
Software Engineering

when (obj) {
1 -> println("One")
int addSomeNums(int x, int y, [int z]) {
int sum = x + y;
Dr. Azanzi Jiomekong
} }
}

University of Yaounde I, Department
console.log(data);
of Computer Science
})
11 avril 2022
1 / 110
} }
}

console.log(data);
})
Copyright (c) 2013 Jiomekong Azanzi Fidèl.

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation ; with
no Invariant Sections, no Front-Cover Texts, and no Back-Cover
Texts. More information about the license is included in the section
entitled ” The GNU Free Documentation License”.
2 / 110
} }
}

console.log(data);
En pratique
})
• Lorsque vous avez une solution logiciel à produire :
◦ Faire l’architecture physique et technique de votre solution
◦ Faire une étude exploratoire des solutions :
• A chaque niveau dans l’architecture, lister les outils possibles
• Faire une étude comparative des outils
• En fonction des résultats de l’étude comparative des outils, choisir l’outil

qui vous convient
3 / 110
} }
}

console.log(data);
Software engineering
})
Main concepts
• Involves the development of software using well-defined scientific

principles, methods and procedures
• Program : executable code, which serves a computational purpose
• Software : collection of executable programs associated with

libraries and documentations
• Software product : software made for a specific requirement
• Engineering : all about developing products, using well-defined,

scientific principles and methods
4 / 110
} }
}

console.log(data);
})
Main components of source code
• Code snippets
• Libraries
• Functions
• Framework
5 / 110
} }
}

console.log(data);
})
Software evolution process
• Requirement gathering process
• Prototype development
• Prototype maintenance and update given till the desired software is

accomplished
• Updating existing software given the advancing technology and the

changing requirements
6 / 110
} }
}

console.log(data);
Software types
})
Software can be divided into three categories :
• S-type (static-type)
• P-type (practical-type)
• E-type (embedded-type)
7 / 110
} }
}

console.log(data);
Software types
})
S-type
• Works strictly according to defined specifications and solutions
• The solution and method to develop are immediately understood

before coding
• Least subjected to changes
• Example : calculator program for mathematical computation
8 / 110
} }
}

console.log(data);
Software types
})
P-type
• Involves a collection of procedures
• Even if the specifications can be described, the solution is not

obvious instantly
• Example : gaming software, word processing software, etc.
9 / 110
} }
}

console.log(data);
Software types
})
E-type
• Works closely as the requirement of real-world environment
• High degree of evolution (changes in laws, taxes, etc.)
• Example : Online trading software
10 / 110
} }
}

console.log(data);
Software types
})
E-type evolution laws (Lehman and Belady, 1974 )
• Continuing change : adapt to the real world changes
• Increasing complexity : evolution increases the complexity
• Conservation of familiarity : changes must implement using

information retained on the development at any cost
• Continuing growth : grows according to the changes of the business
• Reducing quality : can declines in quality unless rigorously

maintained and adapted
11 / 110
} }
}

console.log(data);
Software types
})
E-type evolution laws (Lehman and Belady, 1974 )
• Feedback systems : includes multi-loop, multi-level feedback

systems
• Self-regulation : self-regulating close to normal
• Organizational stability : global activity rate is invariant over the

lifetime of the product
12 / 110
} }
}

console.log(data);
Characteristics of good software

})
• Operational : tells how well software works in operations

−→ budget, Usability, Efficiency, Correctness, Functionality,
Dependability, Security, Safety
• Transitional : how well software works when it moves from one

platform to another
−→ Portability, Interoperability, Reusability, Adaptability
• Maintenance : evaluate the capabilities of the software to maintain

itself in the ever-changing environment
−→ Modularity, Maintainability, Flexibility, Scalability
13 / 110
} }
}

console.log(data);
Programming languages
})
• Permettent de passer du code Algorithmique au code pouvant être

comprise par la machine
• Permettent de décrire les structures de données et les programmes

qui seront manipulés par l’ordinateur
• Il existe une multitude de langages de programmation
• Le passage du code algorithmique au code en langage de

programmation peut se faire totalement à la main ou encore en
utilisant les outils
14 / 110
} }
}

console.log(data);
Software development approaches

})
When we faced to a problem :
• Use existing software :

◦ Word processing : Microsoft Office, LibreOffice, Latex
◦ Epidemiological surveillance : DHIS, OpenMRS
• Develop a new software
• Problems :
◦ heterogeneous network of applications of different design and
developers −→ slowly react on new requirements
◦ Some requirements (health domain) evolve faster (new drugs,
treatment protocols, etc.) −→ Software frequent update :
• Time consuming
• Expensive
• Software regression
15 / 110
} }
}

console.log(data);
Problem of failed software

})
• Result of an unsystematic transfer of business requirements to the

implementation
• Can be avoided if the system is develop/update :

◦ Rapidly
◦ Using a well-defined framework/architecture
◦ With architectural separation of concerns
◦ Assumes the evolutivity, portability, interoperability and reusability
◦ By non-informatics experts who master the software domain
The solution to this problem is Model Driven Architecture :

◦ Architectural separation of concerns
◦ Evolutivity, portability, interoperability and reusability
16 / 110
} }
}

console.log(data);
Models
})
Three different modes in which modeling languages can be used :

Sketch, Blueprint, Programming language
• Sketch :
◦ Informal diagrams used to communicate ideas
◦ Focus on a particular aspect of the system
◦ Are not intended to show every detail of the system modeled
◦ Most useful in code-centric approaches : the objective is to develop
self-explaining code
• Blueprint :
◦ Diagrams that show most of the details of a system in order to foster
its understanding or to provide views of the code in a graphical form
◦ widely used in Model-Based Development (MBD) practices such as
the ones promoted by frameworks such as the Rational Unified
Process (RUP)
17 / 110
} }
}

console.log(data);
Models
})
• Programming language :
◦ Can be used to fully characterize the application
◦ The diagrams replace the code, and they are compiled directly into
executable binaries
◦ Used at the core of Web Engineering Model-Driven Development
(MDD) approaches
18 / 110
} }
}

console.log(data);
Model Driven Engineering

})
• Based on the use of models to develop software artefacts
• Raise the level of abstraction from source code to high-level

domain-specific models
• Developers concentrate on application logic rather than

implementation details
• Improve the productivity and maintainability of software
• Identified in several paradigms :

◦ Model Driven Software Development (MDDS)
◦ Language Oriented Programming (LOP)
◦ Domain-Specific Modelling (DSM)
◦ Framework Specific Modelling (FSM)
◦ Model Driven Architecture (MDA)
19 / 110
◦ etc.
} }
}

console.log(data);
Model Driven Architecture (MDA)

})
• Approach to software design, development and implementation
• Provides guidelines for structuring software specifications expressed

as models
• Uses forward engineering : executable source code automatically

generated from abstract, human-elaborated models
• Consistent use of conceptual models : entities, properties,

relationships
• Reduces the gap between the business level and the information
technology level
• Improve software development process
20 / 110
} }
}

console.log(data);
Model Driven Architecture

})
Primary goals of MDA
• Portability :
◦ Separates the models and the transformations
◦ Height level models do not contain low level platform and technical
details
◦ Model can move across different tools environments
• Interoperability : achieved through horizontal model mapping and

interaction
• Reusability : allows architects and developers the use of existing

software artifacts
21 / 110
} }
}

console.log(data);

})
Main concepts
• Key concepts of MDA : Model and transformation
• Models are defined by a modeling language
• The modeling language is defined by a syntax and a semantic in a

metamodel
• The transformation from one model to another is defined by

transformations rules
22 / 110
} }
}

console.log(data);

})
MDA main concepts
• System : software preexisting or under construction
• Model : allows to formally specify the function, structure and

behaviour of the system
• Model driven : approach to software development using models as

the main source of the analysis, design, development,
documentation, deployment and maintenance of the system
• Architecture : specifications of the parts and connectors of the

system and the rules defining interactions between these parts
using these connectors
23 / 110
} }
}

console.log(data);

})
MDA main concepts
• Platform : set of technologies providing a coherent set of

functionalities to solve a problem
• Platform independency : property of a model which is

independent to the feature of the platform
• Platform model : involve elements, services they provide and

constraints on their use by another part of the system
• Model transformation : process consisting of the conversion of

one model to another one
• Implementation : specifications providing all the information

which are used to construct and put a system into service
24 / 110
} }
}

console.log(data);

})
Models
• Computerized representation of a domain
• Composed of :
◦ Elements : which are the concepts of the domain
◦ Relationships between these elements
• Represent elements using a combination of drawings and text

• Use a graphical notation (e.g., UML) to represent elements
• Allows to :
◦ Well described problems using the terms familiar to people working in
the domain
◦ People involved to communicate and understand each other
25 / 110
} }
}

console.log(data);

})
Models
• Meta Object Facility (MOF) : specification use to define the

abstract syntaxes of several modeling languages
• MOF defines the modeling language and the serialization

mechanism
• Support the overall modeling and transformation process
26 / 110
} }
}

console.log(data);

})
Models pyramid
- MOF
M3 - DL logic
Metametamodel
- UML
M2 - OWL
- BNF2, EBNF3
Metamodel
- UML models
- Ontologies
M1 - Grammarware
Model
- Executable source code
M0 - Knowledge base
- Model ware
Real world
27 / 110
} }
}

console.log(data);

})
Development approaches
• The development by a domain experts :

◦ Domain experts create and maintain specifications of their information
and workflows
◦ Domain experts must master modeling tools
◦ Graphical elements is recommended
◦ Allows to obtain good models for the domain
• The development by a domain experts and an IT experts :

◦ Involve domain experts and the IT experts during the development
◦ Domain expert elaborate the specifications
◦ Textual and graphical elements can be used
◦ IT expert build the model, generate the software and the domain
expert validate the software build
28 / 110
} }
}

console.log(data);

})
Development process
• Construction of the Computational Independent Model

(CIM) :
◦ Contains all the information about the business model
◦ Use the vocabulary familiar to the domain
◦ Presents exactly what the system is expected to do
◦ Example : sequence diagram
• Construction of the Platform Independent Model (PIM) :

◦ Obtained from the CIM
◦ Model free of specific hardware or computing platform requirements
and constraints
◦ Aspects that will not change from one platform to another
◦ Example : class diagram
29 / 110
} }
}

console.log(data);

})
Development process
• Construction of the Platform Specific Model (PSM) :

Obtained by integrating platform (.Net, JEE, etc.) specific details
to PIM
• Generation of executable source code :

◦ Source code generated is obtained from the PSM
◦ Code generated involve : application source code, configuration files,
component descriptor files, deployment files, build scripts,
documentation, etc.
30 / 110
} }
}

console.log(data);

})
Two approaches to consider when developing applications :

• The development by domain experts :
◦ Domain experts directly create and maintain specifications
◦ It entails that they master modelling and the use of the modelling
tools
• The development by domain experts and IT experts :

◦ Involves domain experts and the IT experts during the development
◦ The domain experts elaborate the specifications
◦ The IT experts build the model, generate the software
◦ The domain experts validate the software built
31 / 110
} }
}

console.log(data);

})
Summary
32 / 110
} }
}

console.log(data);

})
MDA tools
• Must be well evaluated selected according to the domain
• Two types of tools :

◦ Tools used to develop MDA tools (model definition and
transformation)
◦ Tools used for software generation
33 / 110
} }
}

console.log(data);

})
Tools used to develop MDA tools
• Eclipse software :
◦ Compound plug-in for graphical and textual model development
◦ Modeling categories involved tools : model development tools, model
transformation tools, concrete syntax development, abstract syntax
development
◦ Modeling standards involved : UML, SysML, OCL, etc.
• Eclipse Modeling Framework (EMF) :

◦ Tools for model definition (based on the metamodel Ecore)
◦ A tool (EMF-Edit) for building editors for EMF models
◦ Code generation facility (EMF.Codegen) to generated everything
needed
34 / 110
} }
}

console.log(data);

})
• Graphical Modeling Framework (GMF) : used to develop graphical

editors based on EMF
• Xpand : use to generate the source code from EMF models
• Xtext : used to develop programming languages and Domain

Specific Languages
• Modeling Workflow Engine (MWE) : used to configure the Xtext

code generator
35 / 110
} }
}

console.log(data);

})
• Atlas Transformation Language (ATL) : EMF model-to-model

transformation language
• Acceleo code generator : used to generate the text (Java, PHP,

Pyton source code) given an EMF model (model-to-text
transformation)
• etc.
36 / 110
} }
}

console.log(data);

})
Tools used for software development
Composed of three main components :

• A domain-specific modeling language/modeling language :
◦ Focused on a particular problem (e.g., patient management)
◦ Designed to address the problem domain directly
◦ Involve domain concepts and rules
◦ specifies the mapping from the model constructed to specific source
code
• A model editor : textual and/or graphical
• A code generator : used to generate source code from the models
Examples of tools : Acceleo, Imogene, EPICAM, AndroMDA

37 / 110
} }
}

console.log(data);

})
Summary
Software
Generation tools source code
Models
Evolution / complements
A need of steps to follow during software development

38 / 110
} }
}

console.log(data);
Software Development Life Cycle

})
• Communication : the user initiates the need for a software
• Requirement gathering
• Feasibility study : project financially, practically and technologically

feasible ?
• System design
• Coding
• Testing
39 / 110
} }
}

console.log(data);

})
• Integration : integration with outer world entities
• Operation and Maintenance : user training, documentation, and

software update according to the changes (environment,
technologies, etc.)
• Disposition : software goes completely obsolete or need intense

upgradation (archiving data and required software components
before the disposition)
40 / 110
} }
}

console.log(data);

})
Requirement gathering
• Discussions (interviews, brainstorming) with stakeholders (users,

developers, decision makers) on the problem
• Studying the existing or obsolete system
• At the end, definition of user requirements, system requirements,

system requirements and functional requirements
41 / 110
} }
}

console.log(data);

})
System analysis
• Understanding of software product
• Analysis of the scope of the project and planing the resources
• The use of actors, use cases and class diagrams are good tools
42 / 110
} }
}

console.log(data);

})
Testing
• Done while coding by the developers
• Conducted by testing experts
43 / 110
} }
}

console.log(data);
Software Development Life Cycle (SDLC)

})
Big Bang Model
Little planing, lots of programming
Does not follow any process
44 / 110
} }
}

console.log(data);

})
Waterfall Model
The whole phases of SDLC will function one after another in linear
manner
Problem : Impossible to undo/redo actions in the previous phases
45 / 110
} }
}

console.log(data);

})
V Model
The software is tested at each stage in reverse manner
At every stage, test plan and case are created to validate the product
46 / 110
} }
}

console.log(data);

})
Iterative Model
Leads the software development process in iterations
Problem : It consumes more resources
47 / 110
} }
}

console.log(data);

})
Spiral Model
Combines both iteration and waterfall model
Allows incremental refinement/releases of the product through each

iteration around the spiral
48 / 110
} }
}

console.log(data);

})
Rapid Application Development (RAD) model
Prototyping and iterative development

No specific planing involved
49 / 110
} }
}

console.log(data);

})
Agile Model
Based on four main principles :

• Iterative : starts by the development of a basic version
• Incremental : after the development of a version (one or many

iteration), an increment, composed of users’ feedbacks and the
new module is launched
• Team-based : people involved must follow the progression of the

development
• User-focused : progressive validation by the final user

(integration/removal of features)
50 / 110
} }
}

console.log(data);

})
Agile Model
Combination of iterative and incremental models

Customer satisfaction by rapid delivery of working software product
51 / 110
} }
}

console.log(data);

})
Problems
• Inconsistency between the development and the production

environment
• For instance :
◦ The development team need agility : the design, build, code is done
continuously
◦ The operational team need stability : but the deployment is linear
−→ consequence :
◦ Conflicts between the dev and the op team of the company
◦ The code works on the developer laptop and bugs on the production
52 / 110
} }
}

console.log(data);

})
Problems
53 / 110
} }
}

console.log(data);
Software Development Environment

})
• Ensemble de programmes pour le développement d’applications
• Un environnement de développement est composé de :

◦ Système d’exploitation
◦ Outils d’analyse et de conception
◦ EDI (IDE en anglais) : Environnement de Développement Intégré
◦ Frameworks : généralement fourni sous la forme d’une bibliothèque
logicielle
◦ Outils de gestion de version du code source
◦ Serveurs
◦ etc.
• Dans le cadre de leurs formations, les étudiants de L3 informatique

sont emmenés à savoir développer les applications
54 / 110
} }
}

console.log(data);

})
Useful tools
• Système d’exploitation : Linux
• Dia, ArgoUML, BouML etc.
• EDI : Eclipse/Netbean, Spring Development Tool (SDT), JUnity

etc. Tout EDI libre
• Les cours et les TPs se dérouleront avec l’EDI Eclipse
• SGBD : postgresQL, mySQL etc. Tout SGBD libre
• Framework : Spring
55 / 110
} }
}

console.log(data);

})
Useful tools
• Serveur JBOSS / WildFly / apache-tomcat
• BIRT / JASPER-iReport
• Google Search, Youtube, G+, stackoverflow.com
56 / 110
} }
}

console.log(data);
Technology Acceptance Model

})
Quality software :
• Productivity : ratio of what is produced to what is required to
produce it
• Satisfaction :
57 / 110
} }
}

console.log(data);
Design pattern
})
• You have a team of developers

• You have a set of projects to develop
• You divide the project and assign to the developer (by the team of
10 for instance)
• Each group of developers can follow different process
• Perhaps others can use the wrong way to build the application
• To ensure that all the team follows the same process/pattern, use
design pattern
• By using design pattern, the developers on different projects us the
same pattern to build similar applications
• Use to be sure that the complete team is at the same and every
body is following the same pattern to build the application
• Simple pattern based on which developers build their applications
• Software template/description to solve a problem that occurs in
multiple instances while designing a software application or a
58 /software
110 framework
} }
}

console.log(data);
Design pattern
})
• Singleton
• Facade
• Adapter
• Decorator
• Dependency Injection
59 / 110
} }
}

console.log(data);
Software project management

})
IT job in a software development company :
• Software creation
• Software project management :

◦ deliver quality product
◦ keeping the costs within client’s budget
◦ constrain and deliver the project as per scheduled
In progress
60 / 110
} }
}

console.log(data);
Programming methods, documentation and challenges

})
Structured programming
• Problem with the development of software and underlying

programs :
◦ difficult to share
◦ difficult to debug
◦ difficult to modify
• Solution : Structured programming - states how the program shall
be coded
61 / 110
} }
}

console.log(data);

})
Uses three main concepts :
• Top-down Analysis : the problem is broken into small pieces and

each pieces is solve individually and combine to form the solution
of the whole problem
• Modular Programming : the code is broken down into smaller

group of instructions called modules, subprograms or subroutines
• Structured Coding : subdivision of the code into smaller units of

code in the order of their execution
62 / 110
} }
}

console.log(data);

})
• Subroutines and loops instead of using simple jumps in the code

• Bring clarity in the code
• Improve code efficiency
• Reduce coding time
• Organize code properly
63 / 110
} }
}

console.log(data);

})
Functional programming
• Uses the concepts of mathematical functions

• A function should produce the same result on receiving the same
argument
• Produces results irrespective of program state (contrary to
procedural programming in which it is possible for a procedure to
produce different results with the same argument)
• Examples of functional programming languages : Lisp, Scala,
Haskell, Erlang
64 / 110
} }
}

console.log(data);
Programming style
})
• Set of coding rules followed by all the programmers to write the

code
• Varies with organizations, operating systems, domain, and

programming languages
• Some appropriate programming style :

◦ using function, constants and variable names relevant to the intended
domain
◦ using well-placed indentation
◦ commenting the code
65 / 110
} }
}

console.log(data);
Software Documentation
})
• Important part of the software process

• Provides information about how to develop and how to use the
product
• Involve :
◦ Requirement documentation
◦ Design documentation
◦
66 / 110
} }
}

console.log(data);
})
Requirement and analysis documents
• Key tool for software designer, developer and the test team
• Contains all the functional, non-functional and behavioral
description of the software
• Obtained from :
◦ Previously stored data about the software
◦ Already running software at the client’s end
◦ Client’s interview
◦ Questionnaires and research
• Used in the analysis, design development and mainly used in
verification and validation
67 / 110
} }
}

console.log(data);
})
Design documentation
• Contains all the needed informations for coding and

implementation
• These are :
◦ High-level software architecture
◦ Software design details
◦ Data flow diagrams
◦ Data base design
◦ Algorithms description
◦ etc.
Work as repository to implement the software
68 / 110
} }
}

console.log(data);
})
Technical documentation
• Maintains by developers and coders

• Increases the understanding between various programmers
• Enhances re-use capabilities of the code
• Makes debugging easy and traceable
• Represent information about the code :
◦ Objective of the code
◦ Who wrote it
◦ Where will it be required
◦ What it does and how it does
◦ etc.
69 / 110
} }
}

console.log(data);
})
User documentation
• Explains how the software should work and how it should be used
• Involve :
◦ Software installation and uninstallation procedure
◦ User guidelines
◦ Software licence
◦ Updation
◦ etc.
70 / 110
} }
}

console.log(data);
Software implementation challenges

})
Code reuse
• Reuse the code created earlier
• Allows to reduce the cost of the end product
• Questions :
◦ How much code to re-use ?
◦ How to check the compatibility ?
71 / 110
} }
}

console.log(data);

})
Version Management
• Version Management - Every time a new software is issued to the

customer, developers have to maintain version and configuration
related documentation. This documentation needs to be highly
accurate and available on time.
72 / 110
} }
}

console.log(data);

})
Target-Host
• Target-Host - The software program, which is being developed in

the organization, needs to be designed for host machines at the
customers end. But at times, it is impossible to design a software
that works on the target machines.
73 / 110
} }
}

console.log(data);
Software maintenance
})
• Includes all the modifications and update done after software

delivery
• Software may be modify for :

◦ Market conditions : taxation, new constraints, etc.
◦ Client requirements : new features may be added by the client over
time
◦ Host modifications : hardware/platform changes may implies the
modification of the software
◦ Organization changes : e.g. acquiring another company
74 / 110
} }
}

console.log(data);
})
Types of maintenance
• Corrective maintenance : correct or fix some problems
• Adaptive maintenance : keep the software up-to date
• Perfective maintenance (new features, user requirements, etc.) :

keep the software usable over long period of time
• Preventive maintenance : prevent future problems
Reports suggest that cost of maintenance is 67% of the cost of the

entire software process cycle
75 / 110
} }
}

console.log(data);
})
Maintenance activities
• Identification & Tracing : generated by users or software logs and

errors messages
• Analysis :
◦ Security and safety implications of the modifications are analyzed
◦ Modifications required is materialized into requirement specifications
◦ The cost of modification/maintenance is analyzed and a decision is
took
◦ Test cases are created for validation
• Design : Modules to be replaced/modify are designed
• Implementation : the module is coded/modified
• System Testing :
◦ Integration testing among created/modified module
◦ Integration testing among created/modified module and the system
◦ Regressive testing of the whole system
• Acceptance testing : the system is tested by the end users
•76 /Delivery
110 : the system is deploy
} }
}

console.log(data);
Software Re-engineering
})
• Keep the functionality of the software and change the design and
the programs
• Done when updating the software becomes a headache (e.g.

hardware/technologies are obsolete)
• Example : Unix was re-engineered from the assembly language to C
77 / 110
} }
}

console.log(data);
})
Software re-engineering process
• Decide what to re-engineer : the whole software or a part of it ?
• Perform Reverse Engineering : allows to obtain specifications of

existing software
• Restructure program is needed (e.g. from function-oriented to

object oriented)
• Restructure data if need be
• Apply forward engineering concepts
78 / 110
} }
}

console.log(data);
})
Main concepts
Reverse Engineering
• Achieve system specification by thoroughly analyzing,
understanding the existing system
• Designer looks at the code and get the design
• Use the design to conclude the specifications
Program Restructuring :
• use to facilitate maintenance and remove obsolete components
• re-structure and re-construct the existing software
• Involve source code, data or both
Forward engineering : obtained desired software from specifications

brought down by means of reverse engineering
79 / 110
} }
}

console.log(data);
EDI
})
• EDI (IDE en anglais) : Environnement de Développement Intégré
• Regroupe un ensemble d’outils pour le développement logiciel
• Permettent la mise en place des fichiers de configuration :

◦ décrire et persister les options de compilation et/ou d’édition de liens
◦ pour automatiser leurs enchaı̂nements
80 / 110
} }
}

console.log(data);
EDI
})
• Regroupe généralement :
◦ un éditeur de texte,
◦ un compilateur,
◦ des outils automatiques de fabrication,
◦ un débogueur,
◦ un système de gestion de versions,
◦ outils facilitant la création des interfaces graphiques
• Certains sont spécialisés (un seul langage de programmation)
• D’autres prennent en compte plusieurs langages (le système de

module permet l’ajout de nouvelles fonctionnalités)
81 / 110
} }
}

console.log(data);
EDI
})
les fonctionnalités des EDI
• Interfaces évoluées : menus, boutons, utilisation combinée

clavier/souris, etc
• Masquent et contrôlent les commandes techniques depuis les IHM
• Evite aux programmeurs débutants d’être confrontés à la syntaxe

du makefile et d’indentation
• Un compilateur (souvent externe) : exemple de gcc ou javac
• Un interprète dans le cas des langages interprétés
• Un débogueur
82 / 110
} }
}

console.log(data);
EDI
})
Quelques fonctionnalités
• selon les langages, on peut avoir des outils supplémentaires :

◦ Assistant au développement d’interface graphique
◦ Interface de gestion de versions
◦ Génération automatique de code source
◦ Modélisation UML
◦ Programmation visuelle : les programmes sont écrits en assemblant les

éléments graphiques (Eclipse EMF, Acceleo)
83 / 110
} }
}

console.log(data);
EDI
})
Quelques EDI
84 / 110
} }
}

console.log(data);
EDI
})
Quelques EDI
• Eclipse :
◦ Originellement dédié à Java
◦ Ses extensions (plug-in) permettent de développer avec un grand
nombre de langages et de technologies (C, C++, PHP, modélisation
UML ...)
• Kdevelop :
◦ Environnement de développement du projet KDE (environnement de
bureau graphique sous Linux)
◦ Initialement dédié à C++ et Qt
◦ Peut gérer Java, PHP, Perl, Python etc.
• Microsoft Visual Studio :
◦ Conçut à l’origine pour le langage C++ et le langage Visual Basic
◦ Devenu l’environnement de référence de la plateforme .Net
◦ Une version gratuite existe : ”Visual Studio Express”
85 / 110
} }
}

console.log(data);
EDI
})
Quelques EDI
• NetBeans :
◦ développé par Sun Microsystems pour Java
◦ le paquetage officiel inclut en plus des technologies JAVA (Java SE,
Java EE, Java FX ...)
◦ intègre le support pour le développement en C++, Ruby et PHP
• phpDesigner :
◦ orienté utilisateur
◦ gère tous les langage Internet reconnus
◦ regroupe en natif tous les outils de développement Internet : html,
Tidy, phpDocumentor, XDebug, SVN ...
• Kompozer : permet de monter les pages web avec le principe
WYSIWYG
86 / 110
} }
}

console.log(data);
EDI
})
Quelques EDI : les EDI spécialisés
• Intègrent les outils pour programmer pour les langages précis :

◦ C++ Builder : pour le développement des applications en C++
◦ WinDev : permet de créer des applications destinées aux PC (crée
par PC Soft)
◦ WebDev : pour créer des applications Internet
◦ WinDev Mobile : permet de créer des applications pour Pocket,
SmartPhone, Iphone, tablette Android et Ipad
◦ codeBlocks : a la particularité de créer des logiciels pour Windows
avec C++, Java
◦ codeBlocks : permet aussi de créer des logiciels mobiles à partir du
langage C++ ou Net pour créer des logiciels pour Android ou iOS
◦ etc.
87 / 110
} }
}

console.log(data);
Frameworks
})
• Ensemble d’outils et de composants logiciels organisés promouvant

un squelette de programme
• Conçus pour aider les programmeurs
• Permettent de créer les fondations ou les grandes lignes de tout ou

d’une partie d’un logiciel (par exemple framework Spring)
• Généralement fourni sous la forme d’une bibliothèque logicielle et

accompagné du plan de l’architecture cible
• Garantissent la baisse des coûts de construction, des délais de

réalisation et une maintenance aisée
88 / 110
} }
}

console.log(data);
Frameworks
})
• Se distingue d’une simple bibliothèque logicielle par son caractère

générique
• Peut être constitué de plusieurs bibliothèques
• Peut être spécialisé sur un langage particulier (Java, C, C++,

etc.), une plateforme spécifique, un domaine particulier (reporting,
mapping etc.)
• Les bibliothèques de classe sont dites passives alors que les

frameworks peuvent être actives (IoC)
89 / 110
} }
}

console.log(data);
Frameworks
})
• Selon les problèmes à résoudre, on distingue :
◦ Framework d’infrastructure système : pour développer des

systèmes d’exploitation des interfaces graphiques, des outils de
communication
◦ Framework d’intégration intergicielle (middleware) : pour fédérer

des applications hétérogènes
◦ Framework d’entreprise : pour développer des applications

spécifiques au secteur d’activité de l’entreprise
◦ Framework de gestion de contenu : fondations d’un système de

gestion de contenu pour la création, la collecte, le classement, le
stockage et la publication de biens numérisés
◦ etc.
90 / 110
} }
}

console.log(data);
Frameworks
})
Exemples de frameworks
91 / 110
} }
}

console.log(data);
APIs
})
In progress
92 / 110
} }
}

console.log(data);
Servers
})
• Outils qui permettent l’exécution de composants côté serveur
• En JAVA, les composants suivants sont exécutés côté serveur

◦ servlets
◦ JSP
◦ EJB
◦ etc.
• Exécutent les composants selon les spécifications de la plate-forme

Java EE
93 / 110
} }
}

console.log(data);
Servers
})
Quelques serveurs d’application
94 / 110
} }
}

console.log(data);
Ant
})
• Outil d’automatisation de la construction d’applications

(compilation, exécution de tâches post et pré compilation, ... )
• Projet du groupe Apache-Jakarta. Son but est de fournir un outil

écrit en Java pour permettre la construction
• Permettent d’automatiser des opérations répétitives tout au long

du cycle de développement de l’application (développement, tests,
recettes, mises en production, ... )
• Indépendant de toute plate-forme
95 / 110
} }
}

console.log(data);
Ant
})
• Reppose sur un fichier de configuration XML qui décrit les

différentes tâches qui devront être exécutées par l’outil
• Fournit un certain nombre de tâches courantes qui sont codées

sous forme d’objets développés en Java
• Les tâches sont donc indépendantes du système sur lequel elles

seront exécutées
96 / 110
} }
}

console.log(data);
Ant
})
• Il est possible d’ajouter ces propres tâches en écrivant de nouveaux

objets Java respectant certaines spécifications
• Le fichier de configuration contient :

◦ un ensemble de cibles (target)
◦ chaque cible contient une ou plusieurs tâches
◦ chaque cible peut avoir une dépendance envers une ou plusieurs autres
cibles pour pouvoir être exécutée
97 / 110
} }
}

console.log(data);
Ant
})
Exemple de fichier de configuration Ant
In progress
98 / 110
} }
}

console.log(data);
Maven
})
• Outil open source qui facilite et automatise certaines taches de la

gestion d’un projet
• Il permet :
◦ D’automatiser certaines tâches : compilation, tests unitaires et
déploiement des applications qui composent le projet
◦ Gérer des dépendances vis à vis des bibliothèques nécessaires au projet
◦ Générer des documentations concernant le projet
◦ Maven est extensible grâce à un mécanisme de plug in qui permet

d’ajouter des fonctionnalités.
99 / 110
} }
}

console.log(data);
Source code management

})
Outils de gestion de code source
• Agit sur une arborescence de fichiers afin de conserver toutes les

versions des fichiers, ainsi que les différences entre les fichiers
• => permet par exemple de mutualiser un développement
• Permet de :
◦ stocker toute évolution du code source
◦ mettre en place un système de mise à jour pour chaque développeur
◦ conserve une trace de chaque changement dans le code source
(chaque changement est accompagné d’un commentaire qui doit être
significatif)
◦ les copies locales et distantes sont fusionnée
◦ chaque nouvelle version d’un fichier :
• est appelée révision
• son numéro est incrémenté de 1 par rapport à la précédente
◦ Quelques outils de gestion de versions : Git, SVN, CVS, BitKeeper
(propriétaire) etc.
100 / 110
} }
}

console.log(data);

})
• Agit sur une arborescence de fichiers afin de conserver toutes les

versions des fichiers, ainsi que les différences entre les fichiers
• => permet par exemple de mutualiser un développement
• Permet de :
◦ stocker toute évolution du code source
◦ mettre en place un système de mise à jour pour chaque développeur
◦ conserve une trace de chaque changement dans le code source
(chaque changement est accompagné d’un commentaire qui doit être
significatif)
◦ les copies locales et distantes sont fusionnée
◦ chaque nouvelle version d’un fichier :
• est appelée révision
• son numéro est incrémenté de 1 par rapport à la précédente
◦ Quelques outils de gestion de versions : Git, SVN, CVS, BitKeeper
(propriétaire) etc.
101 / 110
} }
}

console.log(data);

})
Git
• Logiciel de gestion de version décentralisé
• A été crée (2005) par Linus Torvalds pour le développement du

noyau Linux
• Crée pour remplacer BitKeeper, propriétaire
102 / 110
} }
}

console.log(data);

})
git
103 / 110
} }
}

console.log(data);
Outils de stockage
})
• Les fichiers
• Les bases de données
• Les entrepôts de données
104 / 110
} }
}

console.log(data);
Outils de stockage
})
SGBD
• Système de Gestion de Base de Données
• Logiciel qui permet de stocker des informations dans une base de

données
• Permet de : lire, écrire, modifier, trier, transformer, imprimer les

données qui sont contenus dans la base de données
105 / 110
} }
}

console.log(data);
Outils de stockage
})
SGBD
• Il existe une multitude de SGBD :
◦ Système propriétaire : Oracle Database, Microsoft SQL Server, DB2,

MaxDB, 4D, dBase, Informix, Sybase
◦ Système libre MySQL, PostgreSQL, MariaDB, Firebird, Ingres,

HSQLDB, Derby
◦ Système Orienté objet : ZODB, db4o
◦ Système Embarqué : SQLite, Berkeley DB
106 / 110
} }
}

console.log(data);
Outils de stockage
})
SGBD
• Il existe une multitude de SGBD :
◦ Système NoSQL : Cassandra, Redis, MongoDB, SimpleDB, BigTable,

CouchDB, HBase, LevelDB, RethinkDB, Memcached
◦ Autre système : Access, OpenOffice.org Base, FileMaker,

HyperFileSQL, Paradox, Neo4j
107 / 110
} }
}

console.log(data);
Outils d’analyse et de conception

})
108 / 110
} }
}

console.log(data);
Outils de reporting
})
109 / 110
} }
}

console.log(data);
En pratique
})
• Lorsque vous avez une solution logiciel à produire :
◦ Faire l’architecture physique et technique de votre solution
◦ Faire une étude exploratoire des solutions :
• A chaque niveau dans l’architecture, lister les outils possibles
• Faire une étude comparative des outils
• En fonction des résultats de l’étude comparative des outils, choisir l’outil

qui vous convient
110 / 110

2 Softwareengeneering

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

2 Softwareengeneering

Uploaded by

Copyright:

Available Formats

fun cases(obj: Any) {

when (obj) { int addSomeNums(int x, int y, [int z]) {

INF 3176: Advanced programming

back.on('save-Image', function(filepath, filename, data){

fun cases(obj: Any) {

back.on('save-Image', function(filepath, filename, data){

back.on('save-Image', function(filepath, filename, data){

Copyright (c) 2013 Jiomekong Azanzi Fidèl.

back.on('save-Image', function(filepath, filename, data){

• Lorsque vous avez une solution logiciel à produire :

◦ Faire l’architecture physique et technique de votre solution

◦ Faire une étude exploratoire des solutions :

• A chaque niveau dans l’architecture, lister les outils possibles

• Faire une étude comparative des outils

• En fonction des résultats de l’étude comparative des outils, choisir l’outil

back.on('save-Image', function(filepath, filename, data){

• Involves the development of software using well-defined scientific

• Program : executable code, which serves a computational purpose

• Software : collection of executable programs associated with

• Software product : software made for a specific requirement

• Engineering : all about developing products, using well-defined,

back.on('save-Image', function(filepath, filename, data){

Main components of source code

back.on('save-Image', function(filepath, filename, data){

Software evolution process

• Requirement gathering process

• Prototype maintenance and update given till the desired software is

• Updating existing software given the advancing technology and the

back.on('save-Image', function(filepath, filename, data){

Software can be divided into three categories :

back.on('save-Image', function(filepath, filename, data){

• Works strictly according to defined specifications and solutions

• The solution and method to develop are immediately understood

• Least subjected to changes

• Example : calculator program for mathematical computation

back.on('save-Image', function(filepath, filename, data){

• Involves a collection of procedures

• Even if the specifications can be described, the solution is not

• Example : gaming software, word processing software, etc.

back.on('save-Image', function(filepath, filename, data){

• Works closely as the requirement of real-world environment

• High degree of evolution (changes in laws, taxes, etc.)

• Example : Online trading software

back.on('save-Image', function(filepath, filename, data){

E-type evolution laws (Lehman and Belady, 1974 )

• Continuing change : adapt to the real world changes

• Increasing complexity : evolution increases the complexity

• Conservation of familiarity : changes must implement using

• Continuing growth : grows according to the changes of the business

• Reducing quality : can declines in quality unless rigorously

back.on('save-Image', function(filepath, filename, data){

E-type evolution laws (Lehman and Belady, 1974 )

• Feedback systems : includes multi-loop, multi-level feedback

• Self-regulation : self-regulating close to normal

• Organizational stability : global activity rate is invariant over the

back.on('save-Image', function(filepath, filename, data){

Characteristics of good software

• Operational : tells how well software works in operations

• Transitional : how well software works when it moves from one

• Maintenance : evaluate the capabilities of the software to maintain

back.on('save-Image', function(filepath, filename, data){

• Permettent de passer du code Algorithmique au code pouvant être

• Permettent de décrire les structures de données et les programmes