1 / 23

Challenges in Software Development: Solutions and Strategies in Programming Languages

Explore the perils, challenges, and solutions in software development, covering diverse topics such as programming languages, interface protocols, security, persistence, scalability, and distribution issues. Learn about transparency, static information flow, persistence models, and distributed computing complexities. Discover the implementation strategies and potential solutions to overcome these hurdles in programming. Dive into the dynamic world of software engineering with this insightful guide.

stacyd
Download Presentation

Challenges in Software Development: Solutions and Strategies in Programming Languages

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. 1. Introduction 2 September 02

  2. Writing “Hello World” • Written by a CS 100 programmer: print “Hello world!” • By a CS 211 programmer: • public class Hello { • static void main (String[] argv) { • System.out.println(“Hello world!”); • } • }

  3. Written by an expert: … int _cdecl main(int argc, char * argv[]) { ULONG ulRef; DWORD dwRegistration; CHelloCF *pCF = new CHelloCF(); hEvent = CreateEvent(NULL, FALSE, FALSE, NULL); // Initialize the OLE libraries CoInitializeEx(NULL, COINIT_MULTITHREADED); CoRegisterClassObject(CLSID_CHello, pCF, CLSCTX_LOCAL_SERVER, REGCLS_MULTIPLEUSE, &dwRegistration); // wait on an event to stop WaitForSingleObject(hEvent, INFINITE); // revoke and release the class object CoRevokeClassObject(dwRegistration); ulRef = pCF-Release(); // Tell OLE we are going away. CoUninitialize(); return(0); } … [ uuid(2573F8F4-CFEE-101A-9A9F-00AA00342820) ] library LHello { // bring in the master library importlib("actimp.tlb"); importlib("actexp.tlb"); // bring in my interfaces #include "pshlo.idl" [ uuid(2573F8F5-CFEE-101A-9A9F-00AA00342820) ] cotype THello { interface IHello; interface IPersistFile; }; }; [ exe, uuid(2573F890-CFEE-101A-9A9F-00AA00342820) ]

  4. Perils of writing software • After 30+ years of research and engineering, have to know too much! • Protocols • OLE, COM, Corba, RMI, IP, DNS, TCP, HTTP, Corba, JavaBeans, ‘serialization’… • Languages • Java, C, Perl, sh, Javascript, Visual Basic, make, C++, HTML, XML… • Library/OS interfaces • Unix, X Windows, AWT, Swing, WINNT, …

  5. Problems Stuff CS 211 doesn’t have to deal with: • Concurrency • Reliability • Security • Persistence • Extensibility • Interoperability • Scale and complexity • Configuration management Distribution

  6. Does it have to be this bad? • Lots of (visible) stuff underneath (and above!) your code • Every layer has itsown semantics IDE autoconf Ant/make CVS m4 Application code sh “look-and-feel” lib XML UI base RMI HTTP Serialization JIT compiler Reflection window system file system virtual mem TCP/IP stack m-kernel OS

  7. Cost • Cost of computing systems is: • software development • customization to local environment • training • maintenance • Not: • hardware • The (single-machine) performance problem is solved

  8. Language-based solution • Idea: program in a language expressive enough to hide most of the cruft • existing layer semantics can be embedded in language, made less onerous • Advantages: • Programmers learn one language • Power: some features (e.g., transparent persistence) impossible to provide through procedural interface • Domain-specific languages

  9. Transparency • End-user is given increasingly transparent interface • web sites transparently distributed • files transparently distributed • documents mapped onto file system • differences between content hidden (web pages, files) • content seamlessly encapsulated • Programmers need transparency too • Simple programming model, sophisticated implementation • But what to expose?

  10. An attempt: Java • Some support for concurrency, distribution, security, extensibility • Doesn’t address: reliability, persistence, scale, resource management • Visual Basic, Javascript…

  11. Security • Access control provided by OS (NT) or language (Java) • Language-based: application-specific access rights • Security = data confidentiality, integrity • (D)AC doesn’t enforce system-wide security • access but not propagation • No simple way to validate AC settings • Must prevent improper information flow

  12. Static information flow • Information flows in program analyzed statically • Programs that might violate security are rejected at compile time • Lots of unsolved problems : concurrency, distribution, covert channels, dynamic security policies [Sabelfeld and Myers]

  13. Persistence • What is the right programming (& data) model for accessing persistent data? • Usual persistent data formats don’t look much like popular programming language models of data! • No pointers or object identity, weak referential integrity, no garbage collection, weak or absent types • Considered important for writing correct programs…only needed for volatile data?

  14. Transparent Persistence? • Want safe, fine-grained data sharing across applications, network • Orthogonal persistence: objects transparently persistent or volatile • System makes persistent objects arrive in memory when needed • Result: simpler programming; more robust code; better performance! • Problems: data evolution, software upgrades, distributed computing

  15. Distributed computing • Correct concurrent programs are hard • Distribution is harder: failure-prone components, high-latency communication • Need failure-tolerant programs • automatic failure recovery

  16. Distributed performance • Function shipping: data has home computer, computation moves to data • Data shipping: data moves to host computer • Transfer data or control? Both! • Function shipping (RMI) is good when data is large, bad when control flow is complex (overhead, fragility) • Data shipping good when computation is complex • Can we figure it out automatically?

  17. Consistency/isolation models • Distributed computation: good performance requires caching, else 10’s of ms access time • Caching  stale data  inconsistency • Programmer needs isolation model to write code that works in face of update • Expose transactions in the programming model? • Weak or strong consistency model? • Explicit versioning?

  18. Extensibility • High software development, customization costs  reusable, extensible code • Parametric polymorphism helps • Object-oriented programming helps more • subtyping • inheritance • Still not enough! • multimethods, mixins, open classes, … • linking languages, reflection

  19. Plan • Read mix of recent and classic papers on related topics • Security, concurrency, reliability, persistence, extensibility • 1–2 papers per 50-minute lecture • Participation  Presentation • Come prepared to talk • Read the paper(s) • Discussion is as important as presentation • Outrageous (polite) opinions welcome

  20. Reading • new papers: • PLDI ‘02 • OOPSLA ‘02 • ASPLOS ‘02 • POPL ‘03 (when available) + timeless papers • Some pure PL, some systems + PL. • Paper suggestions welcome • Sign up by sending me mail

  21. Presentation suggestions • Computer projector and laptop will be available. • Aim for a 25-minute talk without interruptions. • Practice your talk at least once before. • Can go over slides with me.

  22. Project • For credit: write a short (4-5k words) paper • project on related topics • survey of work in area

  23. Wednesday • Start talking about security – three papers to read on foundations of information flow www.cs.cornell.edu/andru/cs711

More Related