Liskov Substitution Principle Barbara Liskov first wrote the LSP as follows in 1988:

What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T." - BarbaraLiskov, Data Abstraction and Hierarchy, SIGPLAN Notices, 23,5 (May, 1988).

Principles Of XP	agile	4 October 2003
Every XP aficionado knows about the 4 values and 12 practices, but how many people know about the 15 principles? I'll confess I didn't when Kent talked about them at JAOO last week. After the talk I asked Kent about them: "were they in the White Book". "Yes", he replied, "cunningly hidden in a chapter called 'Basic Principles'". Fundamental Principles: Rapid Feedback Assume Simplicity Incremental Change Embracing Change Quality Work Further Principles: Teach Learning Small Initial Investment Play to Win Concrete Experiments Open, honest Communication Work with people's instincts - not against them Accepted Responsibility Local Adaptation Travel Light Honest Measurement At the JAOO talk, Kent talked about how principles were a step between the universality (and vagueness) of values and the concreteness (and dogmatism) of practices. In the White Book he said "These principles will help us as we choose between alternatives. We will prefer an alternative that meets the principles more fully to one that doesn't. Each principle embodies the values. A value may be vague. One person's simple is another person's complex. A principle is more concrete. Either you have rapid feedback or you don't." The principles haven't been talked about much, even by Kent. I think that's why they aren't so well known. The values and practices were discussed, debated, and refined on the wiki in the formative stages of describing XP. Kent prepared the principles primarily for the White Book. Refreshing my mind with them now, I can see why Kent wanted to remind everyone of them at JAOO. One of the biggest issues with XP, and indeed with any agile method, is how to do the essential local adaptation where you alter the process to fit the local conditions. The principles help provide some guidelines on what bits of adaptation will work, and which go against the XP grain. They are part of the essence of XP that every skilled XPer both knows, and finds difficult to communicate. I'll remember to mention them whenever I describe XP in future.

- www.martinfowler.com

What is the difference between UseCases and XP's stories?

This is a common question, and not one that has a generally agreed on answer. Many people in the XP community consider stories to be a simplified form of use cases, but although I used to hold this view I see things differently now.

Use cases and stories are similar in that they are both ways to organize requirements. They are different in that they organize for different purposes. Use cases organize requirements to form a narrative of how users relate to and use a system. Hence they focus on user goals and how interacting with a system satisfies the goals. XP stories (and similar things, often called features) break requirements into chunks for planning purposes. Stories are explicitly broken down until they can be estimated as part of XP's release planning process. Because these uses of requirements are different, heuristics for good use cases and stories will differ.

The two have a complex correlation. Stories are usually more fine-grained because they have to be entirely buildable within an iteration (one or two weeks for XP). A small use case may correspond entirely to a story; however a story might be one or more scenarios in a use case, or one or more steps in a use case. A story may not even show up in a use case narrative, such as adding a new asset depreciation method to a pop up list.

Do you need to do both? As in many things, in theory you do but in practice you don't. Some teams might use use cases early on to build a narrative picture, and then break down into stories for planning. Others go direct to stories. Others might just do use cases and annotate the use case text to show what features get done when.

Aggregation Or Composition?

aggregation (white diamond) has no semantics beyond that of a regular association. It is, as Jim Rumbaugh puts it, a modeling placebo. People can, and do, use it - but there are no standard meanings for it. So if you see it, you should inquire as to what the author means by it. I would advise not using it yourself without some form of explanation.

composition (black diamond) does carry semantics. The most particular is that an object can only be the part of one composition relationship. So even if both windows and panels can hold menu-bars, any instance of menu-bar must be only held by one whole. This isn't a constraint that you can easily express with the regular multiplicity markers.

- www.martinfowler.com

Principles behind the Agile Manifesto

We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity--the art of maximizing the amount of work not done--is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Manifesto for Agile Software Development

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Abstraction Abstraction is the process of suppressing or ignoring inessential details, while at the same time putting focus on the more important or essential details. Abstraction is typically spoken of in terms of levels, the higher levels addressing why the object exists, and the lower levels leaning more to how it is implemented. There are many types of abstraction, but in terms of objects, the following are important: Functional abstraction, which deals with hiding the functionality within an object, while only exposing the interfaces on how you can interact with it. Data abstraction, which hides the details on how an object's functions and data are implemented. Process abstraction, which manages internal processing of operations.

Encapsulation Encapsulation is the process of logically or physically wrapping together functionality and data that pertains to a unit, business need, or concept into a class or component; that is, information hiding. This concept acts as a software wall or protector, allowing interaction only via specified interfaces; the internals being hidden. Hence, if a change needs to be made to the data or functionality within a class or component, it can take place without cascading changes to the other parts of the system that interact with it.

Concurrency The biggest difference between OO and procedural systems is how they manage concurrency—the capability to process an operation. Non-OO systems will tend to create a broker object or central routine that will take the responsibility of managing how other aspects of the system receive processing requests. OO systems, on the other hand, will tend to leave this process management to the object itself or the environment that object exists within. For example, in the case of EJBs, concurrency is managed by the EJB container.