Review CSU 670 Fall 2003.

Präsentation zum Thema: "Review CSU 670 Fall 2003."—  Präsentation transkript:

1 Review CSU 670 Fall 2003

2 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

3 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.

4 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

5 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

6 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

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

8 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

9 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

10 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)

11 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)

12 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

13 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

14 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?

15 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

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

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

18 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

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

20 Strategy Visitor Adaptive Programming guides and informs
explain strategies Visitor

21 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

22 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 <=.

23 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.

24 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

25 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

26 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

27 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

28 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

29 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

30 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

31 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

32 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.

33 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.

34 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

35 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}.

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

37 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.

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

39 needs Uses explicitly Client Uses implicitly

40 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 ). 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

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

42 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

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

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

45 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

46 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

47 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

48 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

49 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

50 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

51 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

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

53 UML class diagrams object diagrams