1 / 40

22 February

22 February. Implementation. Tournament. Good concept Implementation problems Status: terminate or find an alternative that does not require fixed time or location. Software Engineering Elaborated Steps. Concept Requirements Architecture Design Implementation Unit test

masako
Download Presentation

22 February

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 22 February Implementation

  2. Tournament • Good concept • Implementation problems • Status: terminate or find an alternative that does not require fixed time or location

  3. Software Engineering Elaborated Steps • Concept • Requirements • Architecture • Design • Implementation • Unit test • Integration • System test • Maintenance

  4. Tools • Version Management • Build Systems • Integrated Development Environments

  5. Version Management • Both during and after development • Both code and documentation • Uses • Multi-developer change control • Releases • Support for different environments • Computers • Operating systems

  6. Top Reasons for Using Version Management • Bugs which were fixed reappear • Latest versions of code overwritten by old versions • Which version is the right one? I have so many • I have lost my latest changes

  7. Questions Addressed • Development Issues • How do we integrate parallel work? • How do I know which changes were in the code that was being tested? • Who changed this module? When? Why? • Multi-version Issues • What versions have been made available to people? • How do I assure that all versions get the changes that they need? • What versions need to be re-released to support changes made?

  8. Documentation that Needs Version Control • Manuals: need to reflect the variations of the different releases • Test data: what tests have been run and what was the result • Bug reports • Planned changes • Any document being edited by multiple people

  9. Basic Functions • Ability to add and remove changes • Ability to identify differences • Record of changes made • Storage of different versions • Ability to get access to one or more versions • Identification of all the components needed to build any version

  10. Need a Baseline • Agreed upon document or code level • in large project, formally reviewed and agreed upon • in your project, requires consensus agreement • Basis for further development • in large project, changed only through formal change control procedure • In your project, changed when the developer is “comfortable”

  11. When To Start Using Version Control • Should you use it during unit testing? • What is unit testing? • How much structure does your unit testing require? • If unit testing requires significant infrastructure or scaffolding, it makes sense to start using it very early

  12. No Special Tools Needed • Identify procedures and data needed to • add and remove changes • identify differences • record changes made • store different versions • get access to one or more versions • build any version

  13. But there are tools … • CVS: Concurrent Version System • Subversion (SVN) • SourceForge • Actually uses CVS and SVN, but a different model

  14. Concurrent Versioning System • Developed in the mid 80s • Predecessor RCS (Revision Control System) • Vrije University, Amsterdam • Now open source • Until recently, the most commonly used tool • ximbiot.com/cvs/wiki

  15. What CVS Does • Supports hierarchical directories • manages changes on a per file basis • Remote repository access • import locally for use • Supports parallel development • merges changes • identifies, does not resolve, conflicts • Basic tasks • getting a working copy • committing changes • reverting to prior level • adding or removing a file • synchronizing to the latest code • tagging versions of files

  16. Subversion • http://subversion.tigris.org/ • improved version of CVS • consistent interfaces except for “compelling reasons” • key changes • everything is versioned: directories and file meta-data as well as files • atomic commits • guarantee that all aspects are completed or none are • better performance

  17. SourceForge • Open source development environment • Free web-based facility • Purchasable software as well • SourceForge.net supports • CVS and SVN • Compile farm • Trackers • Web site

  18. Lots of Others • Google code • TRAC

  19. Tools • Version Management • Build Systems • Integrated Development Environments

  20. Build System Functions • System configuration • Executing • preprocessors • compilers • linkers • Manage paths and libraries • Create executables and libraries

  21. Types of Build Systems • Platform • specific • independent • Part of • version management systems • integrated development environments • nothing (standalone)

  22. Platform Specific System: Unix make • Uses a makefile • Can build full systems or parts • Defines dependencies • Simplest example: object file depends on its source file • Executes commands for any (and only) pieces that need to be rebuilt

  23. Open Source Systems:Lots of Them • GNU make • Been around for a while • Cons • Built in Perl • SCons • Python scripts • CMake • cross-platform • used in conjunction with the native build environment • Jam • C and C++ • See also FT Jam (additional platforms)

  24. Apache Ant: build +++ • http://ant.apache.org • Introduction • Workflow elements • XML-based configuration files • Java based • contains features specifically for J2EE

  25. Ant Control Commands (sample) • Ant: Runs Ant on a supplied buildfile • AntCall: Runs another target within the same buildfile • Exec: Executes a system command (can be OS specific) • Java: Executes a Java class • Parallel: Forks a new thread for another Ant tasks • Sequential: Grouping of commands • Waitfor: Blocks execution until a set of specified conditions become true

  26. Tools • Version Management • Build Systems • Integrated Development Environments

  27. Integrated Development Environment • What is an IDE? • A programming environment integrated into a software application • Normally includes • Source code editor • Compiler and or interpreter • GUI development tools • Build system • May also include • Graphical tools (e.g., class hierarchy diagram) • Debugger • Class browser • Version management system

  28. History • Early programming was not done with IDEs • Coding sheets and keypunches • Line command make files • Hardware enhancements • typewriter-like terminals • computer screens • Which of these enabled IDEs? Why?

  29. Dartmouth Time Sharing System (1964) • Command line system • Supported Basic, Algol and FORTRAN • DTSS commands: • NEW, OLD, LIST, SAVE, RUN • Line starting with number replaced that line in the current program • All other commands implied execution • Considered by most people the first IDE

  30. Today’s IDEs • Menu-driven • Proprietary • Microsoft Visual Studio (C#, C++, Visual BASIC) • Borland JBuilder (Java) • Apple XCode (Mac OS X) • Open Source • SharpDevelop (.NET) • GNU Emacs (Unix) – major modes for languages

  31. Eclipse • www.eclipse.org • Both an IDE and an architecture • IDEs • Java, C++, C, C#, Python, PHP, Perl, Smalltalk, CMFL (Coldfusion), Cobol, Fortran, Prolog, Erlang • (you get the idea) • IDE built using architecture • Enhancements through plug-ins

  32. XML • What is it? • Tools • How to use it?

  33. What is XML? • XML - eXtensible Markup Language • A "standard/specification" for describing data with markup tags • Tags can describe data or a structure • XML - cornerstone of a set of technologies • XML can be used alone • Related technologies for most effective use

  34. History of XML • Built on other technologies • GML and SGML – (Standard) Generalized Markup Language: 1960s • Before there was Word and WYSIWYG editors • HTML - HyperText Markup Language • W3C (World Wide Web Consortium) standard

  35. Script Example .ce Introduction.ju .11 39 .ss The work of authors, publishers, and researchers involves, in varying degrees, three recognizable text Formatting commands:.ce center next line .ju justify right margin .ll line length .ss single spacing

  36. Tags • Focus on data description and structure • Element -- a pair of tags with content • Attribute -- specific information about an element • Allow creation of XML Dialects • SMIL -- for multimedia (RealPlayer Multimedia players) • WML -- Wireless WAP-phones • XHTML -- XMLized version of HTML • MathML -- for mathematics • HEML -- historical events

  37. Uses <tag> & </tag> style Markup describes text Focus on presentation Data is text (limited reuse) (Relatively) fixed set of tags Loose syntax End tags assumed Nesting errors affect display Simple and complete Single use - for Web Uses <tag> & </tag> style Markup describes information Focus on data structure Data retains meaning Extensible - can define new tags Stringent syntax End tags required Element nesting enforced Uses related technologies Highly reusable documents HTML XML

  38. Related Technologies • XML schema (XSD replaced DTD) • provides the syntax • defines way elements and attributes represented in a XML document • eXtended Stylesheet Language (XSL) • enables data reuse • transform XML into other XML HTML • format XML for presentation (rendering) • Fonts, size, color, alignment, ... • Rules for ordering

  39. Tools • XML Parser • XSL Processor • Lots and lots of them • Should you use them?

  40. How to Use XML • Key uses • Separation of changeable decisions • Need for multiple forms • Before you invent your own tags, are there relevant ones that you can appropriate? • Use of attributes versus elements • continuing discussion

More Related