COS 240COS 240

Object-Oriented LanguagesObject-Oriented Languages

5.1 Object-Oriented 5.1 Object-Oriented DesignDesign

Object-oriented thinking begins with object-oriented design

“Let there be no doubt that Object-Oriented Design (OOD) is fundamentally different from traditional structured design approaches: it requires a different way of thinking about decomposition and it produces software architectures that are largely outside the realm of the structured design culture.”

Grady Booch, 1994SE guru (UML luminary and author)

“Object-Oriented Analysis and Design with Applications”

Where to start?

As emphasized previously, the most important aspect of O-OP is the creation of a “universe” of largely autonomous (i.e. independent), but still yet interacting objects.

But how does one come up with such a system?

One answer is a design technique driven by the determination and delegation of responsibilities.

The technique described is termed Responsibility-Driven Design (RDD).

Other techniques are available – see COS 315 “Software Engineering”

Programming in the Small and Programming in the Large

• The difference between the development of individual projects and more sizable (real-world) software systems is often described as programming in the small versus programming in the large.

Programming in the Small

• One programmer understands everything from top to bottom.

• Major problem is the development of algorithms.

Programming in the Large

• System is developed by large team of programmers

• Major problems are management of details and communication between programmers and between their respective software subsystems.

Really good design methodologies are required for large, complex real-world problems.

Basis for Design

• Early software development methodologies (those popular before the advent of object-oriented techniques) concentrated on ideas such as characterizing the basic data structures, and/or the overall structure of function calls, often within the creation of a formal specification of the desired application.

• But structural elements (data structures and functions) of the application can be identified only after a considerable amount of problem analysis.

• However, a design technique based on behaviour can be applied from the very beginning of a problem analysis.

Responsibility-Driven Design (RDD), developed by Wirfs-Brock, is an object-oriented design technique that is driven by an emphasis on behaviour at all levels of development.

A low-tech approach to identifying object responsibilities.

Software development with RDD:

1. Analyze problem – use scenarios to “capture” behaviour of real-world objects.

2. Record behaviour on CRC cards.3. Design software objects.4. Code5. Test program

Responsibility-Driven Design

• A design technique that has the following properties:

- Can deal with an ambiguous and incomplete specification (Description of what functionality is required from the program to be developed).

- Naturally flows from analysis to solution.

- Easily integrates with various aspects of software development.

An Simple Example - the IIKH

• Imagine you are the chief software engineer in a major computing firm.

• The president of the firm rushes into your office with a specification for the firm’s next PC-based product. It is drawn on the back of a dinner napkin (as all the best designs are. Not!)

• Briefly, the Intelligent Interactive Kitchen Helper (IIKH) will replace the box of index cards of recipes that may be used in a kitchen.

Abilities of the IIKH

Here are some of the things a user can do with the IIKH:

• Browse a database of recipes

• Add a new recipe to the database

• Edit or annotate an existing recipe

• Plan a meal consisting of several courses

• Scale a recipe for some number of users

• Plan a longer period of meals, say a week

• Generate a grocery list that includes all the items in all the menus for a period

Characterization by Behaviour

• Just as an class is characterized more by behaviour than by representation, the goal in using Responsibility-Driven Design is to first characterize the application by its behaviour – analysis of problem domain.

• First capture the behaviour of the entire application.

• Then refine this into behavioural descriptions of the individual parts (We “capture” the functionality of the software).

• Then map the behavioural descriptions into code.

At first sight, from the problem description, we can see the need for

- “something” to manage a recipe database

- “something” to plan meals

However, we need to analyze the problem in more detail to see if we have missed anything – we usually have!

E.g. from experience, we can see that the user will need some form of menu screen to choose one of the various options.

Working Through Scenarios

• A major technique we use to uncover the desired behaviour is to “walk through” “application scenarios”.

Pretend we have already a working application and “walk through” the various uses of the system.

• Establish the “look and feel” of the system.

• Make sure we have uncovered all the intended uses.

• Develop descriptive documentation.

• Create the high-level software design.

Example: Simple Browsing Scenario Walkthrough

Alice Smith sits down at her computer and starts the IIKH. When the program begins, it displays a graphical image of a recipe box, and identifies itself as the IIKH, product of IIKH Inc. Alice presses the Enter button to begin.

In response to the key press, Alice is given a choice of a number of options. She selects to browse the recipe index, looking for a recipe for salmon that she wishes to prepare for dinner the next day. She enters the keyword salmon, and is shown in response a list of various recipes. She remembers seeing an interesting recipe that used the herb dill as a flavouring. She refines the search, entering the words salmon and dill. This narrows the search to two recipes.

She selects the first. This brings up a new window in which an attractive picture of the finished dish is displayed, along with the list of ingredients, preparation steps, and expected preparation time. After examining the recipe, Alice decides it is not the recipe she had in mind. She returns to the search result page, and selects the second alternative.

Examining this dish, Alice decides this is the one she had in mind. She requests a printing of the recipe, and the output is spooled to her printer. Alice selects “quit” from a program menu, and the application quits.

Software Components

• A software component is simply an abstract design entity with which we can associate responsibilities for different tasks.

• May eventually be turned into a class, a method, or something else.

• In general,

• Any component should have a small well-defined set of responsibilities - called cohesion

• Any component should interact with other components to the minimal extent possible - called coupling

Various types of cohesion and coupling have been identified – see COS 315.

Cohesion and coupling are two good measures of the quality of a program. (Later!)

CRC Cards

• Having identified components, we need to document them.

• Components are most easily described using CRC cards.

• CRC = Component, Responsibility, Collaborator

• A CRC card records the name, responsibilities, and collaborators (i.e. interactions) of an component.

• A CRC card is inexpensive, erasable, physical

• A CRC card is nothing more than a 3x5 index card, on which the analyst writes—in pencil—the name of a class (at the top of the card), its responsibilities (on one half of the card), and its collaborators (on the other half of the card).

• One card is created for each class identified as relevant to the scenario.

• As the team members walk through the scenario, they may assign new responsibilities to an existing class, group certain responsibilities to form a new class, or (most commonly) divide the responsibilities of one class into more fine-grained ones and perhaps distribute these responsibilities to a different class.

What/Who Cycle – Identifying Components

First identify what activity needs to be performed next.

Then answer the question who (i.e. which component) performs that action.

Any activity to be performed by the program must be assigned as a responsibility to some component.

Start with high-level design – general “overview” of how software should function.

Then, step-by-step, add more details – Stepwise Refinement

Development of the IIKH - The Greeter Component

• The first component is the Greeter component.

• When the application is started, the Greeter puts an informative, friendly welcome window (the greeting) on the screen.

• And offers the user the choice of several different actions

- Browse the database of recipes. - Add a new recipe. - Edit or annotate a recipe. - Review a plan for several meals. - Create a plan of meals.

• Many of the details concerning exactly how this is to be done can be ignored for the moment.

Activities are associated with the recipe database and amenu plan – need to create components for these.

The Recipe Database Component

• Ignoring the planning of meals for the moment, next explore the Recipe Database component.

• Responsibilities:

- Must maintain the database of recipes.

- Must allow the user to browse the database.

- Must permit the user to edit or annotate an existing recipe.

- Must permit the user to add a new recipe.

Needs to interact with recipe component.

Responsibilities of the Recipe component

• Can make the recipe itself into an “active” entity – the Recipe component. It maintains information, but also performs tasks.

• Maintains the list of ingredients and transformation algorithm.

• Must know how to edit these data values.

• Must know how to interactively display itself on the output device.

• Must know how to print itself.

• Can add other actions later (ability to scale itself, produce and integrate ingredients into a grocery list, and so on).

The Planner Component

• Returning to the Greeter, we start a different scenario.

e.g. Planning a meal

- This leads to the description of the Planner component.

• Permits the user to select a sequence of dates for planning a meal.

• Permits the user to edit an existing plan.

• Associates with a Date component.

The Date Component

• The Date component holds a sequence of meals for an individual date.

• User can edit specific meals.

• User can annotate information about dates (“Christmas Dinner”, and so on).

• Can print out grocery list for entire set of meals.

The Meal Component

• The Meal component holds information about a single meal.

• Allows user to interact with the recipe database to select individual recipes for meals.

• User sets number of people to be present at meal, and recipes are automatically scaled.

• Can produce grocery list for entire meal, by combining grocery lists from individual scaled recipes.

Postponing Decisions

There are a number of decisions that must eventually be made concerning how best to let the user browse the database.

For example, should the user first be presented with a list of categories, such as “Soups”, “Salads”, “Main meals”,and “Desserts”?

Alternatively, should the user be able to describe keywords to narrow a search, perhaps by providing a list of ingredients, and then see all the recipes that contain those items (“Almonds”, “Strawberries”, “Cheese”), or a list of previously inserted keywords (“Ivan's favourite salad”)?

Should scroll bars be used or should there be simulated thumb holes in a virtual book?

The important point is that such decisions do not need to be made now.

Since they affect only a single component, and do not aaffect the functioning of any other component, all that isnecessary to continue the analysis is to assert that by some means the user can select a specific recipe.

Obviously, this high-level design decision needs to be refined and all the above questions need answers. Some time!

Preparing for Change

It has been said that all that is constant in life is the inevitability of uncertainty and change.

The same is true of software. No matter how carefully one tries to develop the initial specification and design of a software system, it is almost certain that changes in the user's needs or requirements will, sometime duringthe life of the system, force changes to be made in the software.

Software developers need to anticipate this and plan accordingly.

The primary objective is that changes should affect as few components as possible.

Even major changes in the appearance or functioning of an application should be possible with alterations to only one or two sections of code.

Try to predict the most likely sources of change and isolate the effects of such changes to as few software components as possible.

The most likely sources of change are to human-computer interface.

Try to isolate and reduce the dependency of software on hardware.

For example, the interface for recipe browsing in our application may depend in part on the hardware on which the system is running. Future releases may be ported to different platforms. A good design will anticipate this change.

Reducing coupling between software components will reduce the dependence of one upon another, and increase the likelihood that one can be changed with minimal effect on the other.

In the design documentation, maintain careful records of the design process and the discussions surrounding all major decisions.

It is almost certain that the individuals responsible for maintaining the software and designing future releases will be at least partially different from the team producing the initial release.

The design documentation will allow future teams to know the important factors behind a decision and help them avoid spending time discussing issues that have already been resolved.

The Six Components

• Having walked through the various scenarios, eventually we decide everything can be accomplished using only six software components.

Characteristics of Components

• Return to the idea of a software component.

• There are a number of different aspects to this simple idea:

- Behaviour and State

- Instances and Classes

- Coupling and Cohesion

- Service Interface and Implementation

Coupling and Cohesion

• The separation of tasks into the groups of different components should be guided by the concepts of coupling and cohesion.

• Cohesion is the degree to which the tasks assigned to a component seem to form a meaningful unit.

→ Any component must have a small well-defined set of responsibilities.

E.g. performing tasks that are related through the necessity of accessing a common data value.

• Well-designed programs maximize cohesion.

• Coupling is the degree to which the ability to fulfill a certain responsibility depends upon the actions of another component.

• A component should interact with other components to the minimal extent possible.

• In particular, coupling is increased when one software component must access data values (the state) held by another component.

Such situations should almost always be avoided in favour of moving a task into the list of responsibilities of the component that holds the necessary data.

• Well-designed programs minimize coupling.

Formalize the Interface - the next step

• The general structure of each component is identified.

• Components with only one behaviour may be made into methods.

• Components with more than one behaviour are implemented as classes with behaviour as methods.

• Names are given to each of the responsibilities - these will eventually be mapped on to method names.

• For the rest of this section, let us equate component with class.

Designing the Representation

The task now is to transform the description of the class into a software implementation.

Part of this process is designing the data structures that will be used by each class to maintain the state information required to fulfill the assigned responsibilities.

It is also at this point that descriptions of behaviour must be transformed into algorithms using “pseudo-code”.

These descriptions should then be matched against the expectations of each class listed as a collaborator, to ensure that expectations are fulfilled and necessary data items are available to carry out each task.

Pseudo-code – step before actual code

Commonly used, easy to learn – mix of everyday language and programming language

Three types of control structure, derived from structured programming:

- Sequences of instructions

- Selection of alternative instructions (or groups of instructions)

- Iteration (repetition) of instructions (or groups of instructions)

Sequence in Pseudo-code

• Each instruction executed in turn, one after another

E.g.

get client contact name

sale cost = item cost * ( 1 - discount rate )

calculate total bonus

description = new description

Selection in Pseudo-code

• One or other alternative course is followed, depending on result of a test:

if client contact is ’Acme’set discount rate to 5%

elseset discount rate to 2%

end if

Iteration in Pseudo-code

• Instruction or block of instructions is repeated– Can be a set number of repeats– Or until some test is satisfied, for example:

do while there are more staff in the list

calculate staff bonus

store bonus amount

end do

Implementing Components

Once the design of each software class is laid out, the next step is to implement each class's desired behaviour.

If the previous steps were correctly addressed, each responsibility or behaviour will be characterized by a shortdescription (i.e. pseudo-code).

The task at this step is to implement the desired activities in a computer language.

If they were not determined earlier, then decisions can now be made on issues that are entirely self-contained within a single component.

E.g. how best to let the user browse the database of recipes.

Next Step – Implement and Test Components

• Classic techniques, such as stepwise refinement, are used to implement each of the classes.

- More and more detail is progressively added to the design and implementation of the class.

• Classes should be tested in isolation (so-called unit testing), making use of so-called dummy objects or mock objects (Simple dummy objects with no behaviour or with very limited behaviour) for methods external to the class under test.

Class A

Class B

Class C

Example

Class B is “unit” under test.

Class A calls Class B; Class B calls Class C.

But want to test Class B in “isolation”. Class A and Class C may not have been tested yet.

But obviously, there are dependencies between Class A and Class B, and between Class B and Class C.

So, replace the real Class A and Class C with “mock” objects.

Class A

Class B

Class C

A mock object contains no logic other than provide the interface that the class under test requires.

Class A mock object would only contain dummy calls that test out the service interface of Class B.

Class C mock object would only provide a dummy service interface for Class B, and retrun dummy results if necessary.

In the example, it would be reasonable to start testing with the Greeter class.

- To test the Greeter in isolation, mock objects are written for the Recipe Database manager and the daily Meal Plan manager.

- These mock objects need not do any more than print an informative message and return.

- With these, can test various aspects of the Greeter component (for example, that button presses elicit the correct response).

Testing of an individual classes in this way is often referred to as unit testing.

Next Step - Integration Testing

• Classes are then progressively integrated to form a complete system.

• Starting from a simple base, classes are one-by-one added to the system and re-tested, again using mock objects for the as yet un-integrated parts.

For example, the Greeter and the Recipe Databaseclasses may be integrated, maintaining the mock object for the other portion.

Further testing can be performed until it appears that the system as a whole is working as desired. (This is sometimes referred to as integration testing.)

• The application is finally complete when all mock objects have been replaced with the real working classes.

• During integration, it is not uncommon for an error to be manifested in one class, and yet to be caused by a coding mistake in another class.

• Thus, testing during integration can involve the discovery of errors, which then results in changes to some of the classes.

• Following these changes, the affected classes should be once again tested in isolation before an attempt to reintegrate the classes, once more, into the larger system.

Maintenance and Evolution

• Software does not remain fixed after the first working version is released.

• Errors or bugs can be discovered and must be corrected.

• Requirements may change. Say as a result of government regulations, or standardization among similar products.

• Hardware may change.

• Users expectations may change. Greater functionality, more features. Often as a result of competition from similar products.

• Better documentation may be required.

• A good design recognizes the inevitability of change, and plans an accommodation for these activities from the very beginning.

Common Design Flaws

• The following categories present some of the more common design flaws:

- Direct modification - classes that make direct modification of data values in other classes are a direct violation of encapsulation.

- Such coupling makes for inflexible designs.

- Too Much Responsibility - classes with too much responsibility are difficult to understand and to use.

- Responsibility should be broken into smaller meaningful classes and distributed.

- No Responsibility - classes with no responsibility serve no purpose.

- Components with unused responsibility

- Usually the result of designing software classes without thinking about how they will be used.

- Misleading Names

- Names should be meaningful and unambiguously indicate what the responsibilities of the class involve.

Documentation

• Besides CRC cards, it is important that the development of other documentation be performed almost from the beginning.

• The two most important documents are the user manual and the design documentation of the software system.

User Manual

• The user manual describes the application as seen by the user.

• Does not depend upon the implementation, so can be developed before the implementation.

• Can naturally flow from the process of walking through scenarios.

• Can be given to the clients to make sure the users and the implementers have the same ideas.

Quality

• You should always remember that the primary measure of quality is the degree to which your customers (clients) are satisfied with your product.

• Since often customers do not know exactly what it is they want, it is important to work with the client early in the development to make sure the system your are developing is the desired product.

• One very important way to do this is to create the user manual even before the software is written.

• Cohesion and coupling are the major factors in the design of high-quality software.

System Design Documentation

• Record the decisions made during the process of system design.

• Record the arguments for and against any major decision, and the factors influencing the final choice.

• Record CRC cards for the major components.

• Maintain a log of the design progress.

• Important to produce this while the ideas are fresh, not in hindsight when many details will have been forgotten.

• Note the code only records the outcome of decisions, not factors that lead up to decisions being made.

Summary

Object-oriented design differs from conventional software design in that (with the RDD approach) the driving force is the assignment of responsibilities to different software components.

No action will take place without an object to perform the action, and hence every action must be assigned to some member of the object community.

Conversely, the behaviour of the members of the community taken together must be sufficient to achieve the desired goal.

The emphasis on behaviour is a hallmark of object-oriented programming.

Behaviour can be identified in even the most rudimentary descriptions of a system, long before any other aspect can be clearly discerned.

By constantly being driven by behaviour, responsibility-driven design moves smoothly from problem description to software architecture (i.e. organization of code) to code development to finished application.

Questions?Questions?

Questions

1. What are the key features of responsibility-driven design?

2. What are some key differences between programming in-the-small and programming in-the-large?

3. Why can a design technique based on behaviour be applied more easily to poorly-defined problems than can, say, a design approach based on data structures?

4. What is a scenario?

5. What are the basic elements of a component?

6. What is a CRC card? What do the letters stand for?

7. What is the what/who cycle?

8. Why should a user manual be developed before coding begins?

9. What are the major sources of change that can be expected during the lifetime of most long-lived software applications?

10. What information is conveyed by an interaction diagram?

11. What is integration testing?

12. What is software maintenance?

COS 240COS 240

Object-Oriented LanguagesObject-Oriented Languages

5.2. 5.2. Object-Oriented Design Object-Oriented Design NotationNotation

“A picture is worth a thousand words”

O-O program design is usually documented using a diagrammatic format

– “a picture is worth a thousand words”.

There is a standard set of diagrams and notations for describing classes and their interactions.

- Unified Modelling Language (UML) – de facto standard for documenting O-O program designs

The collection of such diagrams is called the design model.

Class Diagram: Class Notation

Class diagram: rectangle with 3 compartments.

Client

companyAddress

companyEmail

companyFax

companyName

companyTelephone

Class name compartment

Attributes compartment

Operations compartment

Class Diagram: Instance Notation

Instance diagram

FoodCo:Client

companyAddress=Evans Farm

companyEmail=mail@foodco.com

companyFax=01589-008636

companyName=FoodCo

companyTelephone=01589-008638

Object name compartment

Attribute values

Instances do not have operations

Class Diagram: Attributes

Attributes are

• Part of the essential description of a class

• The common structure of what the class can ‘know’

• Each object has its own value for each attribute in its class

Class Diagram: Links

FoodCo:Client

Yellow Partridge:Client

Soong Motor Co:Client

Grace Chia:StaffMember

Carlos Moncada:StaffMember

A link is a logical connection between two objects

Class Diagram: Associations

Associations represent

• The possibility of a logical relationship or connection between objects of one class and objects of another

• If two objects can be linked, their classes have an association

Class Diagram: Associations

StaffMember

staffName

staffNo

staffStartDate

Client

companyAddress

companyEmail

companyFax

companyName

companyTelephone

liaises with

staffContact

Association roleAssociation

Association nameDirection in which name should be read

Class Diagram: Multiplicity

• Associations have multiplicity

• Multiplicity is the range of permitted cardinalities of an association

• Represent enterprise (or business) rules

• For example:– A bank customer may have one or more accounts– Every account is for one, and only one, customer

Class Diagram: Multiplicity

StaffMember

staffName

staffNo

staffStartDate

Client

companyAddress

companyEmail

companyFax

companyName

companyTelephone

1 0..*

liaises with

Multiplicities

• Exactly one staff member liaises with each client

• A staff member may liaise with zero, one or more clients

Class Diagram: Operations

Operations are

• An essential part of the description of a class

• The common behaviour shared by all objects of the class

• Services that objects of a class can provide to other objects

Class Diagram: Operations

• Operations describe what instances of a class can do

– Set or reveal attribute values

– Perform calculations

– Send messages to other objects

– Create or destroy links

Campaign

actualCostcampaignFinishDatecampaignStartDatecompletionDatedatePaidestimatedCosttitlecheckCampaignBudget ( )getCampaignContribution ( )recordPayment ( )setCompleted ( )

Aggregation

• An aggregation is a special case of association denoting a “consists of” hierarchy.

• The aggregate is the parent class, and the components are the children classes.

1

Exhaust System

Silencer Tailpipe

0..2

Denoted by a hollow diamond

Aggregation – group dissimilar sets of objects

airplane

fuselage. . .wing landing gear

IS_PART_OFrelationship

è Ignore differences among the parts and concentrateon the fact that they form the whole

Composition

• A solid diamond denotes composition, a strong form of aggregation where the components cannot exist without the aggregate.

3

TicketMachine

Button

Denoted by a solid diamond.

Assume a ticket machinethat has three buttons

Composition and Aggregation – Need to Distinguish

Example: One or more classes consists of zero or more students.

Clearly not composition:– Students could be in several classes– If class is cancelled, students are not destroyed!

Class Student0..*1..*

Example: one meal consists of one or more ingredients.

This is composition:– Ingredient is in only one meal at a time.– If you drop your dinner on the floor, you

probably lose the ingredients too!

Meal Ingredient1..*1

Solid diamond signifies composition

Book

Section

Chapter

*

is_part_of

has*

**

BeerBottle

Crate

**

Examples

Was a test question!

Composition

Aggregation

Generalization

Add generalization structures when

- Two classes are similar in most details, but differ in some respects.

May differ

- In behaviour (operations or methods)

- In data (attributes)

- In associations with other classes

Generalization

• Generalization associations denote inheritance between classes.

• The children classes inherit the attributes and operations of the parent class.

• Generalization simplifies the model by eliminating redundancy.

Button

AcceptButtonCancelButton

Denoted by hollowarrowhead

Generalization - group similar sets of objects

student

postgrad. . .secondary undergrad

IS_Arelationship

superclass/supertype

subclass/subtype

Class Diagram Example

Question

A university offers degrees to students.

The university consists of faculties each of which consists of one or more departments.

Each degree is administered by a single department.

Each student is studying towards a single degree.

Each degree requires one to 20 courses.

A student enrolls in 1-5 courses (per term.)

A course can be either graduate or undergraduate, but not both.

Likewise, students are graduates or undergraduates but not both.

Draw a class diagrams which represents the generic objects and relationships described above.

Make sure to specify multiplicities for all associations shown in your diagrams.

Revision

Class Diagrams

A class diagram depicts classes and their interrelationships.

Next slide shows the simplest possible class diagram, followed by one that contains more details.

Class relationships

Classes have relationships with other classes

- Objects of one class interact with objects from other classes.

This relationship/interaction is termed an association.

Class relationships:

- Association – general- Aggregation- Composition special forms of association- Generalization

Associations

Types of class relationships

A

B

Class Bextendsclass A

Class Ccontains 1 to 4 objectsof class D

Factory

Product

creates

Other kinds ofrelations

Aggregation

Example: “A car consists of a chassis, an engine, wheels, and seats”

The open diamond symbol ◊ denotes aggregation (which means the sum of the parts is the whole).

The diamond is placed on the whole end of the line, not the parts.

Composition

Composition is a stronger form of aggregation.

Example: Every chess board consists of 64 squares

The chess-board relationship is a stronger form of aggregation: It is an instance of composition

Composition also models the part–whole relationship but, in addition,

Every part may belong to only one whole, andIf the whole is deleted, so are the parts

Example: A number of different chess boards.Each square can belong to only one board.If a chess board is thrown away, all 64 squares on that board go as well

Composition is depicted by a solid diamond ♦

Generalization

Inheritance is a feature of object orientation.

- Inheritance is a special case of generalization.

The UML notation for generalization is an open triangle.

Sometimes the open triangle is labeled with a discriminator.

Every instance of Investment Class or its subclasses has an attribute investmentType (the discriminator).

This attribute can be used to distinguish between instances of the subclasses

More examples

Need to know the different types of diagrams and their symbols.

Questions?Questions?