design extractionlabs.cs.upt.ro/labs/acs/html/lectures/4/lecture4.pdf · (0) requirement analysis...

1

Object-Oriented Reengineering

© S. Demeyer, S.Ducasse, O. NierstraszLecture 4

Radu Marinescu

Design Extraction

2



Radu Marinescu

Goals of this Lecture

§ Design is not code with boxes and arrows§ Design extraction is not trivial § Design extraction should scale up§ Design extraction can be supported by computers but not fully automatize§ Give a critic view on hype: “we read your code and produce design”§ Fertilize you with some basic techniques that may help you§ Show that UML is not that simple and clear but still really useful

3



Radu Marinescu

Outline§ Why Extracting Design? Why Uml?§ Basic UML Static Elements§ Interpreting UML§ Language Specific Issues§ Tracks For Extraction§ Extraction Techniques§ Conclusion

4



Radu Marinescu

Why Design Extraction is Needed?

§ Documentation inexistent, obsolete, or too prolix§ Abstraction needed to understand applications§ Original programmers left§ Only the code available

§ Why UML?4 Standard4 Communication based on a common language4 Can support documentation if we are precise about its interpretation4 Extensible

u stereotypes

5



Radu Marinescu

The Reengineering Life-Cycle

Requirements

Designs

Code

(0) requirementanalysis

(1) modelcapture

(2a) problemdetection (3) problem

resolution

(4) Code Transformation

(1) model capture(2) reverse engineeringissues• Scale• Beyond boxes and arrows

(2b) Reverse Engineering

6



Radu Marinescu

War story: “Company X is in trouble.”

Their product is successful (they have 60% of the world market).

But:4 all the original developers left,4 there is no documentation at all,4 there is no comment in the code, 4 the few comments are obsolete, 4 there is no architectural description,...

... and they must change the product to take into account new client requirem.

§ They asked a student to reconstruct the design. ;-)

7



Radu Marinescu

RoadMap§ Why Extracting Design? Why Uml?

§ Basic UML Static Elements4Experimenting With Extraction

§ Interpreting Uml§ Language Specific Issues§ Tracks For Extraction§ Extraction of Intention§ Extraction For The Reuser§ Extraction of Interaction§ Conclusion

8



Radu Marinescu

The Little Static UML

Order Customer

OrderLine

Product

EmployeePersonalCustomer

Corporate Customer

dateReceivedisPrepaidnumber: Stringprice: Money

dispatch()close()

quantity: Integerprice: MoneyisSatified: Boolean

* 1

1

*line items

* 1 nameaddress

creditRating(): String

contactNamecreditRatingcreditLimitremind()billForMonth(Integer)

0..1 *

creditCard#

salesrep

an Association

a Class

some attributes

some operations

9



Radu Marinescu

Let us practice!§ A small example in C++: A Tic-Tac-Toe Game!§ You will do it now........§ But:

4 do not interpret the code 4 do not make any assumption about it4 do not filter out anything

10



Radu Marinescu

A First View

11



Radu Marinescu

Evaluation

§ We should have heuristics to extract the design.§ Try to clean the previous solution you found§ Try some heuristics like removing:

4private information, 4 remove association with non domain entities, 4simple constructors, 4destructors, operators

12



Radu Marinescu

A Cleaner View

13



Radu Marinescu

Roadmap§ Why Extracting Design? Why Uml?§ Basic Uml Static Elements§ Experimenting With Extraction

4 Interpreting Uml§ Tracks For Extraction§ Extraction Techniques§ Conclusion

14



Radu Marinescu

Three Essential QuestionsWhen we extract design we should be precise about:

1. What are we talking about? Design or implementation?

2. What are the conventions of interpretation that we are applying?

3. What is our goal? 4 documentation programmers, 4 framework users, 4 high-level views,

15



Radu Marinescu

Levels of Interpretations: Perspectives§ Fowler proposed 3 levels of interpretations called perspectives [Fowl97a]:

4 conceptual 4 specification4 implementation

§ Three Perspectives:4 Conceptual

u we draw a diagram that represents the concepts that are somehow related to the classes but there is often no direct mapping.

u "Essential perspective"

4 Specificationu we are looking at interfaces of software not implementationu types rather than classes. Types represent interfaces that may have many

implementations

4 Implementationu implementation classes

16



Radu Marinescu

Attributes in Perspectives§ Syntax:

4 visibility attributeName: attributeType = defaultValue4 Example: + name: String

§ Conceptual: 4 Customer name = Customer has a name

§ Specification: 4 Customer class is responsible to propose some way to query and set the name

§ Implementation: 4 Customer has an attribute that represents its name

§ Possible Refinements: Attribute Qualification 4 Immutable: Value never change4 Read-only: Client cannot change it

17



Radu Marinescu

Operations in Perspectives§ Syntax:

4 visibility name (parameter-list) : return-type4 Ex: + public, # protected, - private

§ Conceptual: 4 principal functionality of the object. It is often described as a sentence

§ Specification: 4 public methods on a type

§ Implementation: 4 methods

§ Possible Refinements: Method qualification: 4 Query (does not change the state of an object) 4 Cache (does cache the result of a computation), 4 Derived Value (depends on the value of other values), 4 Getter, Setter

18



Radu Marinescu

AssociationsRepresent relationships between instances

4 Each association has two roles: each role is a direction on the association. 4 a role can be explicitly named, labelled near the target class4 if not named from the target class and goes from a source class to a target

class4 a role has a multiplicity: 1, 0, 1..*, 44 LineItems =

u role of direction Order to OrderLines

4 LineItems role = OrderLine role4 One Order has several OrderLines

OrderdateReceivedisPrepaidnumber: Stringprice: Money

dispatch()close()

OrderLine quantity: Integerprice: MoneyisSatified: Boolean

*

1

LineItems

19



Radu Marinescu

Associations: Conceptual Perspective

Associations represent conceptual relationships between classes4 An Order has to come from a single Customer. 4 A Customer may make several Orders. 4 Each Order has several OrderLines that refers to a single Product.4 A single Product may be referred to by several OrderLines.

OrderCustomer


dispatch()close()

* 1 nameaddress


OrderLine

Productquantity: Integerprice: MoneyisSatified: Boolean

* 1

*

1

20



Radu Marinescu

Associations: Specification Perspective

Associations represent responsibilities4 One or more methods of Customer should tell what Orders a given Customer

has made. 4 Methods within Order will let me know which Customer placed a given Order

and what Line Items compose an Order

Associations also implies responsibilities for updating the relationship, like:4 specifying the Customer in the constructor for the Order4 add/removeOrder methods associated with Customer

Order Customer* 1

21



Radu Marinescu

Arrows: NavigabilityConceptual

4 no real senseSpecification

4 responsibilityu an Order has the responsibility to tell which Customer it is for but Customer don’t

Implementation4 depedenencies

u an Order points to a Customer, an Customer doesn’t

Order Customer


dispatch()close()

* 1 nameaddress


OrderLine

Productquantity: Integerprice: MoneyisSatified: Boolean

* 1

*

1

22



Radu Marinescu

GeneralizationUML semantics only supports generalization and not

inheritance.

§ Conceptual:4 What is true for an instance of a superclass is true for

a subclass (associations, attributes, operations).u Corporate Customer is a Customer

§ Specifications:4 Interface of a subtype must include all elements from

the interface of a superclass

§ Implementation:4 Generalization semantics is not inheritance. 4 But we should interpret it this way for representing

extracted code.

Customer

PersonalCustomer

Corporate Customer


remind()billForMonth(Integer)

creditRating()creditRating()

23



Radu Marinescu

Roadmap§ Why Extracting Design? Why Uml?§ Basic Uml Static Elements§ Experimenting With Extraction§ Interpreting Uml§ Tracks For Extraction§ Extracting of Intention§ Extraction of Interaction§ Conclusion

24



Radu Marinescu

Association ExtractionsGoal: Explicit references to domain classes § Domain Objects

4 Qualify as attributes only implementation attributes that are not related to domain objects.

4 Value objects -> attributes and not associations,4 Object by references -> associations

u String name -- an attributeu Order order -- an associationu Piece myPiece (in C++) -- composition

§ Two classes possessing attributes on each other4 an association with navigability at both side

25



Radu Marinescu

Language Impact on Extraction

§ Attributes interpretation§ In C++

u Piece* myPiece → aggregation or associationu Piece& my Piece → aggregation or associationu Piece myPiece (copied so not shared) → composition

§ In Java4 Aggregation and composition is not easy to extract

u Piece myPiece → attribute or association or aggregation

26



Radu Marinescu

Method Signature for Extracting Relation

§ Having attributes is not always necessary to interact with an object4 temporary references exist:

u temporary variable, method parameter, returned value4 An instance can be dynamically created4 An instance can pass itself as a parameter

§ Do not limit yourself to attributes, methods also contain implicit relationships

void putPiece (int x, int y, Piece piece) u relation between a Board and a Piece

§ When should we extract an aggregation and not a relation is not clear!4 Analyse the language semantics (by copy, by reference)

27



Radu Marinescu

Operation Extraction (1)§ You may not extract

4 accessor methods with the name of an attribute4 operators, non-public methods,4 simple instance creation methods

u new in Smalltalk, constructor with no parameters in Java 4 methods already defined in superclass,4 methods already defined in superclass that are not abstract4 methods that are responsible for the initialization, printing of the objects

§ Use company conventions to filter4 Access to database, 4 Calls for the UI, 4 Naming patterns

28



Radu Marinescu

Operation Extraction (2)§ If there are several methods with more or less the same intent

4 If you want to know that the functionality exists, and not all the details⇒ select the method with the smallest prefix

4 If you want to know all the possibilities, but not all the ways you can invoke them⇒ select the method with the more parameters

§ If you want to focus on important methods⇒ categorize methods according to the number of time they are referenced by clients⇒ but a hook method is not often called but still important

§ What is important to show: the Creation Interface4 Non default constructors in Java or C++

29



Radu Marinescu

Road map§ Why Extracting Design? Why Uml?§ Basic Uml Static Elements§ Experimenting With Extraction§ Interpreting Uml§ Tracks For Extraction

4 Extraction of Intention§ Extraction of Interaction§ Conclusion

30



Radu Marinescu

Design Patterns as Documentation Elements§ Design Patterns reveal the intent

4 so they are definitively appealing for supporting documentation § But...

4 Difficult to identify design patterns from the code u What is the difference between a State and a Strategy from the code p.o.v

4 Need somebody that knows4 Lack of support for code annotation so difficult to keep the use of patterns and the

code evolution

31



Radu Marinescu

Road Map§ Why Extracting Design? Why Uml?§ Basic Uml Static Elements§ Experimenting With Extraction§ Interpreting Uml§ Language Specific Issues§ Tracks For Extraction§ Extracting of Intention§ Extraction of Interactions§ Conclusion

32



Radu Marinescu

Documenting Dynamic Behaviour§ Focusing only at static element structural elements (class, attribute, method)

is limited, does not support: 4 protocols description (message A call message B)4 describe the role that a class may play e.g., a mediator

§ Calling relationships is well suited for 4 method interrelationships4 class interrelationships

§ UML proposes Interaction Diagrams 4 Sequence Diagram or Collaboration Diagram

33



Radu Marinescu

Sequence Diagrams§ A sequence diagram depicts a scenario

by showing the interactions among a set of objects in temporal order.

§ Objects (not classes!) are shown as vertical bars.

§ Events or message dispatches are shown as horizontal (or slanted) arrows from the send to the receiver.

§ Recall that a scenario describes a typical example of a use case, so conditionality is not expressed!

caller lifts receiver

dial tone begins

dial (1)

dial tone ends

dial (2)

dial (2)

ringing tone phone rings

answer phone

ringing stopstone stops

Caller Phone Line Callee

34



Radu Marinescu

Statically Extracting Interactions§ Pros:

4 Limited resources needed4 Do not require code instrumentation

§ Cons:4 Need a good understanding of the system

u state of the objects for conditionalu compilation state #ifdef...u dynamic creation of objects

§ Potential behavior not the real behavior4 Blur important scenario

35



Radu Marinescu

Dynamically Extracting Interactions§ Pros:

4 Help to focus on a specific scenario4 Can be applied without deep understanding of the system

§ Cons: 4 Need reflective language support

u MOP, message passing control or code instrumentation (heavy)4 Storing retrieved information

u may be huge

§ For dealing with the huge amount of information4 selection of the parts of the system that should be extracted, selection of the

functionality4 selection of the use cases4 filters should be defined

u several classes as the same, several instance as the same...

§ A simple approach:4 open a special debugger that generates specific traces

36



Radu Marinescu

Lessons Learnt § You should be clear about:

4 Your goal (detailed or architectural design)4 Conventions like navigability, 4 Language mapping based on stereotypes4 Level of interpretations

§ For Future Development4 Emphasize literate programming approach4 Extract design to keep it synchronized

§ UML as Support for Design Extraction4 Often fuzzy4 Composition aggregation limited 4 Do not support well reflexive models4 But UML is extensible, define your own stereotype

design extractionlabs.cs.upt.ro/labs/acs/html/lectures/4/lecture4.pdf · (0) requirement analysis...

Documents