Presentation is loading. Please wait.

Presentation is loading. Please wait.

Software engineering Olli Alm Lecture 6: implementation, tools for software development.

Similar presentations


Presentation on theme: "Software engineering Olli Alm Lecture 6: implementation, tools for software development."— Presentation transcript:

1 Software engineering Olli Alm Lecture 6: implementation, tools for software development

2 Software engineering tools  Development tools Integrated Developent Enviroment (IDE), application server, database administration, tools for testing...  Tools for communication Email, phone, skype, conferencing tools, instant messaging, chat, twitting, facebook, google wave...  Content delivery & management 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

3 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

4 Software development tools: IDE  An example: Eclipse www.eclipse.org

5 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

6 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

7 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?)

8 Best practices Best practices: (for Java) http://www.javapractices.com/home/HomeAction.do http://www.javapractices.com/home/HomeAction.do (for PHP) http://net.tutsplus.com/tutorials/php/30-php-best- practices-for-beginners/ http://weierophinney.net/matthew/uploads/php_develop ment_best_practices.pdf (incl. communication!)

9 Coding conventions For PHP: http://www.evolt.org/node/60247 http://drupal.org/coding-standards http://framework.zend.com/manual/en/coding- standard.html

10 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)

11 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

12 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)

13 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

14 Version control / distributed software development  An answer: communicate with email, send files? E.g. 3 people editing (the same) 4 files:

15 Version control / distributed software development  An answer: communicate with email, send files? E.g. 3 people editing (the same) 4 files:

16 Version control / distributed software development  An answer: communicate with email, send files? E.g. 3 people editing (the same) 4 files:

17 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!

18 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)

19 Version control / distributed software development  Communicate with version control, E.g. 3 people editing (the same) 4 files: Centralized service

20 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

21 Version control platforms Server-client:  Subversion / SVN http://subversion.tigris.org/http://subversion.tigris.org/ Distributed:  Mercurial http://mercurial.selenic.com/http://mercurial.selenic.com/  GIT http://git-scm.com/http://git-scm.com/ http://en.wikipedia.org/wiki/Revision_control http://en.wikipedia.org/wiki/List_of_revision_control_software

22 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? ...

23 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)

24 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?'

25 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

26 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.)

27 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


Download ppt "Software engineering Olli Alm Lecture 6: implementation, tools for software development."

Similar presentations


Ads by Google