Software engineering - Personal web pages for people of Metropolia

Download Report

Transcript Software engineering - Personal web pages for people of Metropolia

Software engineering
Lecture 6: implementation, tools for software development
Olli Alm
Software engineering tools

Development tools


Tools for communication


Email, phone, skype, conferencing tools, instant
messaging, chat, twitting, facebook, google wave...
Content delivery & management


Integrated Developent Enviroment (IDE), application
server, database administration, tools for testing...
Version control, document management / Content
Management Systems (CMS), wiki
Documentation tools

Writing: e.g. Open Office, MS Office, Latex..

Diagrams: e.g. Jude, MS Visio, Eclipse plugins...

Illustration / mock-ups: drawing tools, e.g. GIMP

Presentations: e.g. Powerpoint
Software development tools: IDE
IDE: Integrated Development Environment
(”ohjelmointiympäristö”)







Source code editor
Compiler
Debugger
Builder
Server management
Binding classes & libraries
Extensions


Version control, user interface development, testing,
automatic code generation, …
The extreme opposite: text editor + command line compiling +
set of separate tools
Software development tools: IDE

An example: Eclipse www.eclipse.org
Software development tools: IDE
Examples on ”low level” assistance:

Code highlightning

Compile automatically

Code assistance

Resource linking (classes, libraries)

Documentation linking

Working with the workspaces, projects
Software development tools: IDE
Examples on ”high level” assistance:

DB access: generate interface classes

Unit tests: generate test classes

Deploy web application immediately

Import web service classes automatically

Wrap the project into package for delivery /
publishing
Implementation issues
Coding
 What language to use?
 Best practices, coding conventions?
 Commenting, documentation
 IDE + assisting tools
 Web application or not? (installation, configuration,
concurrency, prototyping, updates, testing,
availability?)
Best practices
Best practices:
(for Java)
http://www.javapractices.com/home/HomeAction.do
(for PHP)
http://net.tutsplus.com/tutorials/php/30-php-bestpractices-for-beginners/
http://weierophinney.net/matthew/uploads/php_develop
ment_best_practices.pdf
(incl. communication!)
Coding conventions
For PHP:
http://www.evolt.org/node/60247
http://drupal.org/coding-standards
http://framework.zend.com/manual/en/codingstandard.html
Commenting

Automatic generation of code documentation:(Javadoc
example):
http://java.sun.com/j2se/javadoc/writingdoccomments/

Clarify unclear parts, do not repeat the code in comments

Comments for clarifying what is missing (TODO, FIXME)
Dependable development (Sommerville: Ch.20)

Dependable process (SE8 ch.20 p.466)




Predefined process model that defines the results and
activities
Verification & validation
Robustness: ability to recover from failed activities
Emphasis on requirements






Requirements inspections
Requirements management (keeping up-to-date)
Model consistency checking (CASE tools)
Design & code inspections
Static (code) analysis
Test planning & management
Dependable development (CH.20)

Dependable programming (SE8 ch.20)


Protect information (objects, accessor methods, private
data!), prefer strong typing!
Anti-patterns for critical systems (avoid these if
possible!):







Floating point numbers (use fixed points!)
Pointers
Dynamic memory allocation (reserve memory in
advance!), unbounded arrays
Be careful on paralleism, concurrency, timing issues
Recursion
Interrupts, inheritance, aliasing (=naming conventions)
(split the code into small enough parts)
Version control / distributed software development

Management of the code


Easy when there is one person, difficult when there is
more people involved
Code: text files


Same files are edited by many people
The problem: how to propagate changes to people?


People in the same room vs. people in the other country?
How to ensure that the different files are working correctly with
each other
Version control / distributed software development

An answer: communicate with email, send files?

E.g. 3 people editing (the same) 4 files:
Version control / distributed software development

An answer: communicate with email, send files?

E.g. 3 people editing (the same) 4 files:
Version control / distributed software development

An answer: communicate with email, send files?

E.g. 3 people editing (the same) 4 files:
Version control / distributed software development

An answer: communicate with email, send files?

E.g. 3 people editing (the same) 4 files:
3 different versions of each file,
4^3: 64 different combinations of files
 Difficult!
Version control / distributed software development


Another answer: use version control software
Version control



A software to maintain the state information of the files
Usually centralized service on a server machine
Used for




communication (add/remove/change file)
revision history
Software: CVS, SVN (SubVersioN), GIT (by Linus
Torvalds), Mercurial
An example: page history / revisions in MediaWiki (e.g.
en.wikipedia.org)
Version control / distributed software development

Communicate with version control,

E.g. 3 people editing (the same) 4 files:
Centralized service
Version control / distributed software development

Version control functionalities / jargon




Checkout: get the local copy of the files from the server
Update: update the local copy from the server
Commit: send the (local) modifications to the server
Revision: a numbered version of the server files


Revisions form the history of the project
Merging: combining the two versions of a file

If possible, done automatically by the version control
software
Version control platforms
Server-client:
 Subversion / SVN http://subversion.tigris.org/
Distributed:
 Mercurial http://mercurial.selenic.com/
 GIT http://git-scm.com/
http://en.wikipedia.org/wiki/Revision_control
http://en.wikipedia.org/wiki/List_of_revision_control_software
Communication

In a SE project, with the development team, with the
customer, with other parties

In the development process, how to:

report bugs?

ask detailed information about a component?

announce progress, current weeks schedule?

announce meeting hours?

negotiate change in requirements?

...
Communication

Email:




Good in one-to-one communication
Not the best tool for collaborative working (e.g. document
writing)
Difficult to manage in one-to-many communications
Good for ”archiving”, records daily activities, records
decisions made (=be careful)
Communication

Chat:



Good for getting an immediate response (for a minor
issue)
Usually the content (e.g. description, opinions) is
expressed in a relaxed way
'Is this ready?', 'What's the due for the component xx?'
Communication

Twitting, profile updates (e.g. in Facebook):


Good for expessing low-priority (non-urgent) information
in one-to-many communications. Suitable for telling what
you are doing today (~Scrum meetings)
One-way communication: not really expecting response
for the message
Communication

Face-to-face, phone meetings



For getting an agreement on something
To get started on something, to explore, to analyze
things, meet face-to-face.
(as opposed to messaging systems, urgent requests are
harder to discard / bypass.)
Communication

Indirect communication through the document or content
management system is also possible:

e.g. wait for the specific document update, start working
after that

Central repository with identified users

Version control

Support for tracking specific / recent changes

Wiki-engines

Google docs