Review CSU 670 Fall 2003

The goal of good software development The goal is to separate concerns (each decision in a single place) and minimize dependencies between them (loose coupling): less tangled code, more natural code, smaller code concerns easier to reason about, debug and change a large class of modifications in the definition of one concern has a minimum impact on the others more reusable, can plug/unplug as needed

What is software development? Software Development is a resource-limited) cooperative game of invention and communication. The primary goal of the game is to deliver useful, working software. The secondary goal of the game is to set up for the next game. The next game may be to alter or replace the system or to create a neighboring system.

Types of Requirements Engineering Greenfield Engineering Development starts from scratch, no prior system exists, the requirements are extracted from the end users and the client Triggered by user needs Re-engineering Re-design and/or re-implementation of an existing system using newer technology Triggered by technology enabler Interface Engineering Provide the services of an existing system in a new environment Triggered by technology enabler or new market needs Example: Eclipse as new technology enabler

Use Cases A use case is a flow of events in the system, including interaction with actors It is initiated by an actor Each use case has a name Each use case has a termination condition Graphical Notation: An oval with the name of the use case Use Case Model: The set of all use cases specifying the complete functionality of the system

Categories of software development methodologies Object-oriented methodology Systems are modeled as a collection of cooperating objects Structured Methodology Based on functional (algorithmic) decomposition Data-driven Methodology Structure of system is derived by mapping system inputs to outputs. E,g, Jackson System Development Aspect-oriented Methodology Support for crosscutting abstractions E.g. Demeter, AspectJ, HyperJ

The Waterfall Model of the Software Life Cycle Requirements Analysis and Definition System and Software Design System Testing Implementation and Unit Testing

Problems with Waterfall Model Managers love waterfall models: Nice milestones No need to look back (linear system) Always one activity at a time Easy to check progress during development: 90% coded, 20% tested However, software development is iterative While a design is being developed, problems with requirements are identified While a program is being coded, design and requirement problems are found While a program is tested, coding errors, design errors and requirement errors are found

Problems with Software Structuring Data (Shapes) + Functions (Colors) 1st Generation Spaghetti-Code 4th Generation object decomposition in den vorherigen Kapiteln wurde erklärt: 1. in der Informatik darum, Rechnermodelle zu bauen, die Prozessen in der reellen Welt simulieren. 2. Es gibt formale Mitteln, die es erlauben, die Modelle in eine für den Rechner verständlich en Sprache zu schreiben.t. In dieser Vorlesung erden wir das sogenannte objekt-orientierte Programmiermodel als das Mittel für die Beschreibung der Modelle benutzen. Mit anderen Worten, werden wir objekt-orientierte Rechnermodelle der reellen Welt bauen. Wir werden zuerst, die Konstrukte des objekt-orientierten Programmiermodels kennenlernen, d.h. die Bestandteile unsere Toolboxes. Als zweites werden wir kurz 2nd & 3rd Generation : functional decomposition © 1999 Mira Mezini

Problems with Functional Decomposition Advantage: easy integration of new functions Disadvantage: Data spread around integration of new data types ==> modification of several functions functions tangled due to use of shared data Difficult to localize changes ! in den vorherigen Kapiteln wurde erklärt: 1. in der Informatik darum, Rechnermodelle zu bauen, die Prozessen in der reellen Welt simulieren. 2. Es gibt formale Mitteln, die es erlauben, die Modelle in eine für den Rechner verständlich en Sprache zu schreiben.t. In dieser Vorlesung erden wir das sogenannte objekt-orientierte Programmiermodel als das Mittel für die Beschreibung der Modelle benutzen. Mit anderen Worten, werden wir objekt-orientierte Rechnermodelle der reellen Welt bauen. Wir werden zuerst, die Konstrukte des objekt-orientierten Programmiermodels kennenlernen, d.h. die Bestandteile unsere Toolboxes. Als zweites werden wir kurz Software = Data (Shapes) + Functions (Colors)

Problems with Object Decomposition Advantage: easy integration of new data Disadvantage: functions spread around integration of new functions ==> modifikation of several objects objects tangled due to higher-level functions involving several classes Difficult to localize changes ! in den vorherigen Kapiteln wurde erklärt: 1. in der Informatik darum, Rechnermodelle zu bauen, die Prozessen in der reellen Welt simulieren. 2. Es gibt formale Mitteln, die es erlauben, die Modelle in eine für den Rechner verständlich en Sprache zu schreiben.t. In dieser Vorlesung erden wir das sogenannte objekt-orientierte Programmiermodel als das Mittel für die Beschreibung der Modelle benutzen. Mit anderen Worten, werden wir objekt-orientierte Rechnermodelle der reellen Welt bauen. Wir werden zuerst, die Konstrukte des objekt-orientierten Programmiermodels kennenlernen, d.h. die Bestandteile unsere Toolboxes. Als zweites werden wir kurz Software = Data (Shapes) + Functions (Colors)

Problems with Object Decomposition high-level behavior scattered around the implementation of several classes OOAD Z Collab-1 C1 C4 C2 C3 C5 Collab-4 Collab-2 Collab-3 C1 Object-oriented languages do not provide adequate constructs to capture collaborations between several classes. Has been recognized in different forms in the object-oriented community: OO accommodates the addition of new variants of data types better than procedural programming but, the opposite is true when new operations on existing data types are needed visitor pattern: the matter of concern -- definition of new operations on an existing object structure (aggregation is involved besides inheritance) several works complain the lack of constructs for expressing collaboration-based designs C4 C2 C3 C5 Implementation Collaboration -- a distinct (relatively independent aspect of an application that involves several participants, or roles roles played by application classes each class may play different roles in different collaborations each role embodies a separate aspect of the overall class behavior Collaboration-based design s Require to view oo applications in two different ways: (a) in terms of participants or types involved (b) in terms of the tasks or concerns of the design

Problems with Object Decomposition in den vorherigen Kapiteln wurde erklärt: 1. in der Informatik darum, Rechnermodelle zu bauen, die Prozessen in der reellen Welt simulieren. 2. Es gibt formale Mitteln, die es erlauben, die Modelle in eine für den Rechner verständlich en Sprache zu schreiben.t. In dieser Vorlesung erden wir das sogenannte objekt-orientierte Programmiermodel als das Mittel für die Beschreibung der Modelle benutzen. Mit anderen Worten, werden wir objekt-orientierte Rechnermodelle der reellen Welt bauen. Wir werden zuerst, die Konstrukte des objekt-orientierten Programmiermodels kennenlernen, d.h. die Bestandteile unsere Toolboxes. Als zweites werden wir kurz During implementation separate higher-level functions are mixed together During maintenance/evolution individual collaborations need to be factored out of the tangled code

So what? NO ! So, let’s organize!! Let’s have aspects “Forget about objects” [Udell, BYTE, May 94] NO ! So, let’s organize!! Let’s have aspects that capture functions that cross cut class boundaries !! Let’s have aspects to reconcile functions and objects The point is merely that objects are too low-level. If we don’t follow certain principles, we easily end up with “hyper spaghetti’’ objects Collaborations are not explicit in the software. This is what ACs will support. So why?

Reconciling objects and functions: the intuition behind aspectual collaborations modification in den vorherigen Kapiteln wurde erklärt: 1. in der Informatik darum, Rechnermodelle zu bauen, die Prozessen in der reellen Welt simulieren. 2. Es gibt formale Mitteln, die es erlauben, die Modelle in eine für den Rechner verständlich en Sprache zu schreiben.t. In dieser Vorlesung erden wir das sogenannte objekt-orientierte Programmiermodel als das Mittel für die Beschreibung der Modelle benutzen. Mit anderen Worten, werden wir objekt-orientierte Rechnermodelle der reellen Welt bauen. Wir werden zuerst, die Konstrukte des objekt-orientierten Programmiermodels kennenlernen, d.h. die Bestandteile unsere Toolboxes. Als zweites werden wir kurz result expected provided adapters Concrete application

AP Late binding of data structures Programming without accidental data structure details yet handling all those details on demand without program change

Concepts needed (DJ classes) ClassGraph Strategy Visitor ObjectGraph TraversalGraph (efficiency) ObjectGraphSlice (efficiency)

Strategy ClassGraph ObjectGraph Adaptive Programming is use-case based Bold names refer to DJ classes. is use-case based abstraction of ClassGraph New: abstractions of class diagrams notice affinity to design patterns: some of them also talk about families of class structures explain strategies defines family of ObjectGraph

Strategy ObjectGraph ObjectGraphSlice Adaptive Programming defines traversals of ObjectGraph plus Strategy defines explain strategies ObjectGraphSlice

Strategy Visitor Adaptive Programming guides and informs explain strategies Visitor

Software Design and Development with DJ (very brief) Functional decomposition into generic behavior Decomposition into methods Decomposition into traversal strategies Decomposition into visitors Adaptation of generic behavior Identify class graph Identify traversal strategies

Definition: Class Graph A class graph is a directed graph with a partial order on the nodes. We write c1 -> c2 for the edges (construction edges) and c1 <= c2 for the order (inheritance edges -- c1 is a subclass of c2). We write => for the inverse of <=.

Relations We think of directed graphs as relations. Write C(c1,c2) or c1 C c2 for edge from c1 to c2 in C. Composition of relations by . E.g., x (R.S) z iff there is a y such that xRy and ySz. R* is the reflective transitive closure of a relation R.

Strategy: From X1 to T e o1:X1 o2:X2 declared type of target of e is X3 =>X2 e go down e iff X1 <=.e X3 =>.(<=.C.=>)*.<=) T if only construction edges: go down e iff X1 e X3 C* T

z Strategy S -> T x X1 Y1 Z1 y S X2 Y2 Z2 T t X3 Y3 Z3 x y z t s1:S x31:X3 y31:Y3 z31:Z3 t1:T go down e iff S <=.C X1 =>.(<=.C.=>)*.<=) T

z Strategy S -> T x X1 Y1 Z1 y S X2 Y2 Z2 T t X3 Y3 Z3 x y z t s1:S x31:X3 y31:Y3 z31:Z3 t1:T go down e iff S <=.C X1 =>.(<=.C.=>)*.<=) T

z Strategy S -> T x X1 Y1 Z1 y S X2 Y2 Z2 T t X3 Y3 Z3 x y z t s1:S x31:X3 y31:Y3 z31:Z3 t1:T <=,=> not used go down e iff S <=.C X1 =>.(<=.C.=><=.C.=><=.C=>).<=) T

Example strategy A -> T T -> D a1:A 0..1 :D r1:R X 0..1 B c1:C s1:S D A C s2:S t1:T 0..1 r2:R object graph R S T 0..1 c2:C class graph d2:D go down e iff A <=.C R =>.(<=.C.=>)*.<=) T

Example 2 S = from BusRoute through Bus to Person busStops BusRoute BusStopList buses 0..* NGasPowered BusStop BusList waiting 0..* passengers Bus PersonList Person 0..* DieselPowered

Example 2 OG : BR BL DP PL P OG’: BR BL B PL P SG : BR B P Only node paths shown for space reasons Route1:BusRoute BusList buses busStops :BusStopList Bus15:DieselPowered passengers CentralSquare:BusStop waiting :PersonList :PersonList Joan:Person Paul:Person Seema:Person Eric:Person S = from BusRoute through Bus to Person

Example 3 OG : BR BL OG’: BR BL SG : BR Only node paths shown for space reasons early termination Route1:BusRoute BusList buses busStops :BusStopList Bus15:DieselPowered passengers CentralSquare:BusStop waiting :PersonList :PersonList Joan:Person Paul:Person Seema:Person Eric:Person S = from BusRoute via NGasPowered to Person

A simple view of traversals When a traversal reaches a target node in the object graph, the path traversed from the source, with suitable substitution of subclasses by superclasses, must be an expansion of an s-t path in the strategy graph. s is the source and t is the target of the strategy. Each edge in the strategy graph corresponds to at least one edge in the object graph.

A simple view of traversals When a traversal reaches a final node in the object graph without being at a target, the path traversed from the source, with suitable substitution of subclasses by superclasses, must be a prefix of an expansion of an s-t path in the strategy graph. The prefix is the longest prefix such that there is still a possibility of success as determined by the class graph.

Object Graph Slice The object graph slice starting with o1 is the slice built by following the edges selected by the path regular expression starting at o1 and continuing until every path terminates (at an object of type t or if it terminates prematurely). go down e iff X1 <=.e X3 =>.(<=.C.=>)*.<=) T

Strategy definition: embedded, positive strategies Given a graph G, a strategy graph S of G is any subgraph of the transitive closure of G. The transitive closure of G=(V,E) is the graph G*=(V,E*), where E*={(v,w): there is a path from vertex v to vertex w in G}.

Transitive Closure busStops BusRoute BusStopList buses 0..* BusStop BusList waiting 0..* passengers Bus PersonList Person 0..*

Strategy graph and base graph are directed graphs Key concepts Strategy graph S with source s and target t of a base graph G. Nodes(S) subset Nodes(G) (Embedded strategy graph). A path p is an expansion of path p’ if p’ can be obtained by deleting some elements from p.

Law of Demeter Client Interface Implementation Client restricts use of Avoid ubiquitous interface Exposure. Implementation

needs Uses explicitly Client Uses implicitly

class dictionaries (11 kinds) inductive nonleft-recursive 9 10 11 8 7 6 1 2 LL(1) 3 1: ideal case 2: JavaCC does not complain (Oct. 30 1997). Grammar contains useless symbols. Ok if we don’t want to parse but forces cyclic objects. 4 nonambiguous 5 Venn Diagram 11/24/2018 AOO / Demeter

Patterns Patterns Structure-shy Traversal Selective Visitor Structure-shy Object Class Graph Growth Plan Pattern

Three layers of Demeter instance of defines classes Demeter behavior and aspect files B: metamodel L: model P: user objects CB your behavior and aspect files CL metamodel OB classes model OL TB user object OP a class dictionary for class dictionaries objects TL class dictionary TP text sentence

Icon Use as reminder for Demeter Tiling. Demeter Tiling CB OB CL TB OL TL OP TP

Example ??? Demeter Tiling CB OB CL Basket TB OL TL OP TP aBasket:Basket With respect to the project class dictionary as OB

Example Vertex (or Ident) Demeter Tiling CB OB CL Basket TB OL TL OP TP Basket aBasket:Basket With respect to the project class dictionary as OB

Example ??? Demeter Tiling CB OB CL Regular_Syntax TB OL TL OP TP aRegular_Syntax:Regular_Syntax With respect to the project class dictionary as OB = OL

Example Vertex Demeter Tiling CB OB CL Regular_Syntax TB OL TL OP TP aRegular_Syntax:Regular_Syntax With respect to the project class dictionary as OB = OL

Example ??? Demeter Tiling CB OB CL TB OL TL OP TP Labeled = <label_name> Ident ... <b> With respect to the project class dictionary as OB = OL

Example Adjacency = <source> Vertex ... Demeter Tiling CB OB CL TB OL TL OP TP Labeled = <label_name> Ident ... <b> With respect to the project class dictionary as OB = OL

Example ??? Demeter Tiling CB OB CL TB OL TL OP TP Adjacency = <source> Vertex ... A = <b> B <b> B. With respect to the project class dictionary

Example Adjacency = <source> Vertex ... Demeter Tiling CB OB CL TB OL TL OP TP Adjacency = <source> Vertex ... A = <b> B <b> B. With respect to the project class dictionary

Lightweight Software Development Method Extreme Programming lots of testing, write test cases early incremental development pair programming

UML class diagrams object diagrams