1 / 17

Skills Talk

Skills Talk. Techniques for significant software engineering tasks. 21 st January 2008 Simon Fothergill 3 rd year PhD student. Outline. UML : What, why and how? Program verification : Theory and practise Typesetting code : in editor and in documents Questions

fifi
Download Presentation

Skills Talk

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. Skills Talk Techniques for significant software engineering tasks 21st January 2008 Simon Fothergill 3rd year PhD student

  2. Outline • UML : What, why and how? • Program verification : Theory and practise • Typesetting code : in editor and in documents • Questions • Vignettes, not technically challenging, but worth drawing ones attention to, even if not vigorously upheld!

  3. UML : What? • Unified Modelling Language • Object orientated software analysis & design • Born out of 3 similar methodologies at OMG • Language, not process • Practical tools : Many Eclipse plug-ins Views • For modelling at different stages of the design process • E.g. use-case, design, deployment Diagrams • For modelling at different aspects of the system • Behaviour • Structure • E.g. Sequence, class, object, state-chart

  4. UML : Why? • Models : abstraction : cope with complexity & correct mistakes early • Standard : Communication, inter-operability, verification • Thorough : Useful, pre-defined levels of abstraction & model elements

  5. UML : Example (class diagram of Decorator design pattern) Component package Operation() Component->Operation() ConcreteComponent Decorator Operation() Operation() Decorator::Operation(); AddedBehaviour(); ConcreteDecoratorA ConcreteDecoratorB Operation() Operation() addedbehaviour addedstate

  6. UML : Example (sequence interaction diagram) client : Order : OrderLine * : Customer getTotal() *getValue() getShippingCost() GetLocation()

  7. Program Verification • Invariants : Expressions that express a desired, “consistant” state, for a duration or at a specific point in an executing program. • If it is true, for/at this time, everything’s good! • By increasing the state space of a program with meta-data about the invariants, compilers can provide some automated verification.

  8. Program Verification • Immediate invariants, true every time a certain point in the code is reached. Can catch logical errors in algorithms. • Object invariants, true, if an expression involving the objects data, holds. Catches misuse of data.

  9. Program Verification • Previous, flawed methods Callers concerns with pre/post conditions No information hiding Implicit pre and post conditions of true Recursive call could cause assert to fail Just establish invariant as post condition

  10. Program Verification • A Better approach o :: T public field o.st = {Valid, Invalid} for use in specifications only Can only alter o.st using pack and unpack Newly instantiated objects are Invalid Invariant only uses members of its class Can only update Invalid objects

  11. Program Verification • Example Now the state is invalid, so recursive call would not meet M’s preconditions

  12. Program Verification : Practial advise • Java’s assert statement can be used for pre/post conditions and invariants • JML : Java Modelling Language has functionality for using ensures/requires and extensions on this idea. It also has a hack for information hiding.

  13. Typesetting code : in the editor • Compound words • Underscore • Concatenation + capitalisation • Class / Variable / method names: • Classnames • CONSTANTS • CLASS/Instance variables • CLASS/Instance methods • localVariables • Iterators, counters, accumulators (i,j,k,count,acc) • Indentation • Brackets • Inlining / Compression of simple expressions Catch (IOException e) {if (n<0) {e.getMsg();}} • Capitalisation

  14. Typesetting code : in documents Beware • Part of the notation (quotes, line breaks, indentation) • Hyphenation can be misleading • Size of tabs • Number of characters per line • Monospacing for columnular languages • Case Consider • Font • Stand out • No need for serif fonts • Differentiate comments and keywords • Don’t confuse 1,l,I,0,O,o • Justification can not be helpful

  15. Typesetting code : example Taken from “On the typesetting of computer programs, Esmond Pitt, Melbourne Software Company”, page 10

  16. References • Practical Object-Oriented Design with UML; Mark Priestley; McGraw Hill; ISBN: 0-07-709599-5 • Design Patterns, Elements of Reusable Object-Oriented Software; Gamma, Helm, Johnson, Vlissides, Addison-Wesley, ISBN: 0-201-63361-2 • Verification of object orientated programs with invariants; Barnett & co; JOT 2004, Vol. 3, No. 6 • On the typesetting of computer programs, Esmond Pitt, Melbourne Software Company (http://www.rmiproxy.com/javarmi/TypesettingComputerPrograms.pdf)

  17. The end! Any questions?

More Related