1 / 71

Software Development

Software Development. CSU 670 www.ccs.neu.edu/home/lieber/courses/csu670/f03/f03.html. Introduction. Software engineering, modeling, design, software architecture, software processes Programming languages Hands-on, practical, useful. Summary of Course.

jdillman
Download Presentation

Software Development

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. Software Development CSU 670 www.ccs.neu.edu/home/lieber/courses/csu670/f03/f03.html CSU 670/1

  2. Introduction • Software engineering, modeling, design, software architecture, software processes • Programming languages • Hands-on, practical, useful CSU 670/1

  3. Summary of Course • How to design and implement flexible object-oriented software using the principles of adaptiveness and separation of concerns in combination with UML and Java. Learning principles behind XML. • How to design and implement flexible 100% pure Java software minimizing scattering and tangling of crosscutting behavioral concerns. CSU 670/1

  4. Who is in Attendance? • Software developers who have experience with object-oriented programming. • Should know concepts of OOP, like classes, methods, and late binding. • Software developers who know about formal languages and automata: grammars, non-terminals, terminals. CSU 670/1

  5. Academic Integrity • Tension • Learning from your peers: is valuable • for technical help; “this program does not run properly and I have tried for two hours to figure out why; can I explain my program to you?” • for discussing ways to think about the concepts • for home work and project work if you work in a team of two (encouraged: pair programming!) • for getting a concept explained • for sharing frustrations • Independent scholarship CSU 670/1

  6. Academic Integrity • Independent scholarship • Required for exams • Required for giving presentations in class • Required for succeeding CSU 670/1

  7. Important Rules • Learn when to go inside and solve the problems yourself. • Learn when it is appropriate to use help from a peer. CSU 670/1

  8. Featured in MIT Technology Magazine 2001 as a Top Ten Technology Agenda Aspect-Oriented Progr. Adaptive Programming DemeterJ Java and DJ Java environment UML XML strategy graphs class graphs object graphs state graphs principles heuristics patterns idioms theorems algorithms requirements domain analysis design implementation use cases interfaces traversals visitors packages Demeter Method iterative development spiral model Extreme Programming CSU 670/1

  9. Aspect-Oriented Software Development (AOSD) • Observation: many concerns of the designer/programmer are scattered across many classes or methods and tangled with code of other concerns. • A concern is called crosscutting, if its ad-hoc implementation is scattered. • AOSD is about cleanly modularizing crosscutting concerns. A modularized crosscutting concern is called an aspect. • Reduces scattering and tangling. CSU 670/1

  10. Agenda • UML class diagrams. Perspective: analysis, design, implementation • Class graphs as special cases of UML class diagrams • Textual representation of class graphs • Default implementation of UML class diagrams as class graphs CSU 670/1

  11. Agenda • UML interaction diagrams • sequence diagrams • collaboration diagrams • improving interaction diagrams to make them specification languages • XML data type definitions and documents CSU 670/1

  12. Agenda • Class graphs in textual form (construction, alternation) • object graphs (graphical and textual form) • object graphs defined by class graphs • add repetition classes and optional parts • translating class graphs to Java CSU 670/1

  13. Agenda • annotating class graph with syntax: class dictionary • printing objects and language defined by class dictionary • grammars, parsing, ambiguous grammars, undecidable problem • LL(1) grammars, robustness of sentences • etc. CSU 670/1

  14. Overview • good separation of concerns is the goal • concerns should be cleanly localized • programs should look like designs CSU 670/1

  15. Adaptive Programming • Programs adapt to interesting context changes • Structure-shy behavior • Succinct representation of traversals • Programming in terms of graph constraints CSU 670/1

  16. Cross-cutting of concerns better program ordinary program structure-shy functionality Components structure Aspect 1 synchronization Aspect 2 CSU 670/1

  17. interface ShapeI extends Remote { double get_x() throws RemoteException ; void set_x(int x) throws RemoteException ; double get_y() throws RemoteException ; void set_y(int y) throws RemoteException ; double get_width() throws RemoteException ; void set_width(int w) throws RemoteException ; double get_height() throws RemoteException ; void set_height(int h) throws RemoteException ; void adjustLocation() throws RemoteException ; void adjustDimensions() throws RemoteException ; } publicclass Shape implements ShapeI { protected AdjustableLocation loc; protected AdjustableDimension dim; public Shape() { loc = new AdjustableLocation(0, 0); dim = new AdjustableDimension(0, 0); } double get_x() throws RemoteException { returnloc.x(); } void set_x(int x) throws RemoteException { loc.set_x(); } double get_y() throws RemoteException { returnloc.y(); } void set_y(int y) throws RemoteException { loc.set_y(); } double get_width() throws RemoteException { returndim.width(); } void set_width(int w) throws RemoteException { dim.set_w(); } double get_height() throws RemoteException { returndim.height(); } void set_height(int h) throws RemoteException { dim.set_h(); } void adjustLocation() throws RemoteException { loc.adjust(); } void adjustDimensions() throws RemoteException { dim.adjust(); } } publicclass Shape { protecteddouble x_= 0.0, y_= 0.0; protecteddouble width_=0.0, height_=0.0; double get_x() { return x_(); } void set_x(int x) { x_ = x; } double get_y() { return y_(); } void set_y(int y) { y_ = y; } double get_width(){ return width_(); } void set_width(int w) { width_ = w; } double get_height(){ return height_(); } void set_height(int h) { height_ = h; } void adjustLocation() { x_ = longCalculation1(); y_ = longCalculation2(); } void adjustDimensions() { width_ = longCalculation3(); height_ = longCalculation4(); } } Write this coordinator Shape { selfex adjustLocation, adjustDimensions; mutex {adjustLocation, get_x, set_x, get_y, set_y}; mutex {adjustDimensions, get_width, get_height, set_width, set_height}; } class AdjustableLocation { protecteddouble x_, y_; public AdjustableLocation(double x, double y) { x_ = x; y_ = y; } synchronizeddouble get_x() { return x_; } synchronizedvoid set_x(int x) {x_ = x;} synchronizeddouble get_y() { return y_; } synchronizedvoid set_y(int y) {y_ = y;} synchronizedvoid adjust() { x_ = longCalculation1(); y_ = longCalculation2(); } } class AdjustableDimension { protecteddouble width_=0.0, height_=0.0; public AdjustableDimension(double h, double w) { height_ = h; width_ = w; } synchronizeddouble get_width() { return width_; } synchronizedvoid set_w(int w) {width_ = w;} synchronizeddouble get_height() { return height_; } synchronizedvoid set_h(int h) {height_ = h;} synchronizedvoid adjust() { width_ = longCalculation3(); height_ = longCalculation4(); } } portal Shape { double get_x() {} ; void set_x(int x) {}; double get_y() {}; void set_y(int y) {}; double get_width() {}; void set_width(int w) {}; double get_height() {}; void set_height(int h) {}; void adjustLocation() {}; void adjustDimensions() {}; } Modularization of crosscutting concerns Instead of writing this CSU 670/1

  18. Aspect-Oriented Programming components and aspect descriptions High-level view, implementation may be different Source Code (tangled code) weaver (compile- time) CSU 670/1

  19. Examples of Aspects • Collaborations, use cases • Synchronization of methods across classes • Remote invocation (using Java RMI) • Quality of Service (QoS) • Failure handling • External use (e.g., being a Java bean) • Replication, Migration CSU 670/1

  20. Connections • explain adaptive programming in terms of patterns • Aspect-Oriented Programming (AOP) is a generalization of Adaptive Programming (AP) • correspondence: adaptive program : object-oriented program = sentence : object graph CSU 670/1

  21. Vocabulary • Graph, nodes, edges, labels • Class graph, construction, alternation • Object graph, satisfying class graph • UML class diagram • Grammar, printing, parsing CSU 670/1

  22. Vocabulary • Traversals, visitors • Strategy graphs, path set CSU 670/1

  23. Overview this lecture • Basic UML class diagrams • Traversals/Collaborating classes • Traversal strategy graphs • Adaptive programming • Tools for adaptive programming • DemeterJ and AP/Studio CSU 670/1

  24. 1: Basic UML class diagrams • Graph with nodes and directed edges and labels for nodes and edges • Nodes: classes, edges: relationships • labels: class kind, edge kind, cardinality CSU 670/1

  25. UML Class Diagram busStops BusRoute BusStopList buses 0..* BusStop BusList waiting 0..* passengers Bus PersonList Person 0..* CSU 670/1

  26. 2: Traversals / Collaborating classes • To process objects we need to traverse them • Traversal can be specified by a group of collaborating classes CSU 670/1

  27. Collaborating Classes use connectivity in class graph to define them succinctly using strategy graphs from Customer to Agent from Company to Employee CSU 670/1

  28. self-service Z customer service teller service center What's the problem? TANGLING OOAD Collab-1 C1 C4 C2 C3 C5 Collab-4 Collab-2 Collab-3 C1 C4 C2 C3 Implementation C5 CSU 670/1

  29. Collaborating Classes find all persons waiting at any bus stop on a bus route busStops BusRoute BusStopList OO solution: one method for each red class buses 0..* BusStop BusList waiting 0..* passengers Bus PersonList Person 0..* CSU 670/1

  30. TPP section: Decoupling and the Law of Demeter • Write shy code: • A shy person does not interact with too many people. • A shy method does not interact with too many classes/objects. CSU 670/1

  31. 3: Traversal Strategy Graphs • Want to define traversals succinctly • Use strategy graphs to express abstraction of class diagram • Express traversal intent: useful for documentation of object-oriented programs CSU 670/1

  32. find all persons waiting at any bus stop on a bus route Traversal Strategy first try: from BusRoute to Person busStops BusRoute BusStopList buses 0..* BusStop BusList waiting 0..* passengers Bus PersonList Person 0..* CSU 670/1

  33. find all persons waiting at any bus stop on a bus route Traversal Strategy from BusRoute through BusStop to Person busStops BusRoute BusStopList buses 0..* BusStop BusList waiting 0..* passengers Bus PersonList Person 0..* CSU 670/1

  34. find all persons waiting at any bus stop on a bus route Traversal Strategy Altern.: from BusRoute bypassing Bus to Person busStops BusRoute BusStopList buses 0..* BusStop BusList waiting 0..* passengers Bus PersonList Person 0..* CSU 670/1

  35. find all persons waiting at any bus stop on a bus route Robustness of Strategy from BusRoute through BusStop to Person villages BusRoute BusStopList busses VillageList busStops 0..* 0..* BusStop BusList Village waiting 0..* passengers Bus PersonList Person 0..* CSU 670/1

  36. Filter out noise in class diagram • only three out of seven classes • are mentioned in traversal • strategy! from BusRoute through BusStop to Person replaces traversal methods for the classes BusRoute VillageList Village BusStopList BusStop PersonList Person CSU 670/1

  37. Why Traversal Strategies? • Law of Demeter: a method should talk only to its • friends: • arguments and part objects (computed or stored) • and newly created objects • Dilemma: • Small method problem of OO (if followed) or • Unmaintainable code (if not followed) • Traversal strategies are the solution to this dilemma CSU 670/1

  38. TPP: Tip 53: Abstractions Live Longer than Details • Is in the Requirements Pit section • Also applies to code: don’t overspecify! CSU 670/1

  39. 4: Adaptive Programming • How can we use strategies to program? • Need to do useful work besides traversing: visitors • Incremental behavior composition using visitors CSU 670/1

  40. Styles of Adaptive Programming • Traditional: parameterize by class graph; strategy is part of adaptive program • Traditional optimized: parameterize by class graph and strategy graph; reuse pair of class graph and strategy graph. CSU 670/1

  41. Writing Adaptive Programs with Strategies (DJ=pure Java) String WPS=“from BusRoute through BusStop to Person” classBusRoute{ int countPersons(ClassGraph cg) { String WPS=“from BusRoute through BusStop to Person” Integer result = (Integer) cg.traverse(this, WPS, new Visitor(){ int r ; public void before(Person host){ r++; } public void start() { r = 0;} public Object getReturnValue() {return new Integer ( r);} }); return result.intValue();} } CSU 670/1

  42. Writing Adaptive Programs with Strategies (DJ=pure Java) // Prepare the class graph ClassGraph classGraph = new ClassGraph(); int r = aBusRoute.countPersons(classGraph); CSU 670/1

  43. TPP section: The Evils of Duplication • Tip 11: DRY – Don’t Repeat Yourself • Imposed duplication without tool support CSU 670/1

  44. Goal of DJ • Focus on crosscutting traversal-related concerns: involve a group of collaborating objects which are manipulated to implement a behavior. • Provide a Java library to cleanly encapsulate crosscutting traversal-related concerns whose ad hoc implementation would be scattered across many classes. CSU 670/1

  45. Solves Problem in AOPfor Behavioral Aspects in Java • The ClassGraph-Aspect-Freezing problem • When we have n behavioral aspects and the class graph changes, we potentially need to update all n aspects. • DJ allows us to loosely couple behavioral aspects to the class graph. • And this is all done in Java using REFLECTION. CSU 670/1

  46. Writing Adaptive Programs with Strategies (DJ=pure Java) String WPStrategy=“from BusRoute through BusStop to Person” classBusRoute{ int countPersons(TraversalGraph WP) { Integer result = (Integer) WP.traverse(this, new Visitor(){ int r ; public void before(Person host){ r++; } public void start() { r = 0;} public Object getReturnValue() {return new Integer ( r);} }); return result.intValue();} } CSU 670/1

  47. Writing Adaptive Programs with Strategies (DJ=pure Java) String WPStrategy=“from BusRoute through BusStop to Person” // Prepare the traversal for the current class graph ClassGraph classGraph = new ClassGraph(); TraversalGraph WPTraversal = new TraversalGraph (WPStrategy, classGraph); int r = aBusRoute.countPersons(WPTraversal); CSU 670/1

  48. Writing Adaptive Programs with Strategies (DJ=pure Java) classUtility{ static int countPersons(ObjectGraphSlice countSlice){ Integer result = (Integer) countSlice.traverse(new Visitor(){ int r ; public void before(Person host){ r++; } public void start() { r = 0;} public Object getReturnValue() {return new Integer ( r);} }); return result.intValue(); } } CSU 670/1

  49. Writing Adaptive Programs with Strategies (DJ=pure Java) String WPStrategy=“from BusRoute through BusStop to Person” // Prepare the slice for the current class graph ClassGraph classGraph = new ClassGraph(); ObjectGraph objectGraph = new ObjectGraph(aBusRoute, classGraph); ObjectGraphSlice whatToCount = new ObjectGraphSlice(objectGraph, WPStrategy); int r = Utility.countPersons(whatToCount); CSU 670/1

  50. Writing Adaptive Programs with Strategies (DemeterJ) strategy: from BusRoute through BusStop to Person BusRoute { int printCountWaitingPersons() // traversal/visitor weaving through BusStop to Person (PrintPersonVisitor); } PrintPersonVisitor { before Person {{ … }} … } PersonVisitor {init {{ r = 0; }} … } THIS IS NOT JAVA Extension of Java: keywords: init through bypassing to before after etc. CSU 670/1

More Related