************ Lean [POPPENDIECK-2003] Chapter 1, 2 **************************************************

Lean is: “A systematic approach to identifying and eliminating waste through continuous improvement, flowing the

product at the pull of the customer in pursuit of perfection.” Lean is centered around preserving value with less work.

Lean Software Development is the application of lean principles to the craft of software development.

Just-in-time approach. Stop trying to maximize local efficiencies.

Practice: Stop-the-Line culture.

1. Preoccupation with failure

2. Reluctance to simplify

3. Sensitivity to operations

4. Commitment to learn from mistakes

5. Deference to expertise

The Toyota Product Development System, Four cornerstone

elements:

1. System design by an entrepreneurial leader

2. Expert engineering workforce

3. Responsibility based planning and control

4. Self-based concurrent engineering

Principles are underlying truths that don’t change over time or space, while practices are the application of principles to a particular situation. The learn-by-doing approach: Adopt a coherent set of practices with confidence that this will eventually lead to understanding of the principles behind them. Then there is an understand-before-doing approach: Understand the underlying principles, and use them to develop practices for specific situations.

Software Embedded software is the part of a product that is expected to change. If it didn’t need to change, then it might as well be hardware. Development is the process of transforming ideas into products. Kanban is a method for managing the creation of products with an emphasis on continual delivery while not overburdening the development team. Seven Principles of Lean Software Development

1. Eliminate waste. A common agile development practice is the ‘retrospective’, which is the process of the team

meeting after each short iteration to discuss what went well, what didn’t, and what could be done differently in

the next iteration. This iterative process of learning and continual improvement is an important part of

identifying waste and eliminating it.

2. Build quality in. There are quality assurance processes designed to avoid quality issues in the first place.

Examples of this are Pair Programming, Test Driven Development, constant feedback and automation. Myth:

The Job of Testing Is to Find Defects

3. Create Knowledge. Things to do to help create knowledge: Pair programming, code reviews, documentation,

wiki, commented code, knowledge sharing sessions, training. Myth : Predictions Create Predictability

4. Defer Commitment. Decide as late as possible, particularly for decisions that are irreversible, or at least will be

impractical to reverse. Architect the solution so that fewer commitments are irreversible. And defer

commitment on irreversible decisions to the latest point possible. Myth: Planning Is Commitment

5. Deliver Fast. An effective organization doesn’t demand teams do more than they are capable of, but instead

asks them to self-organize and determine what they can accomplish. Constraining these teams to delivering

potentially shippable solutions on a regular basis motivates them to stay focused on continuously adding value.

Myth: Haste Makes Waste

6. Respect People. The implication is that you need a lean governance strategy that focuses on motivating and

enabling IT teams—not on controlling them. Myth: There Is One Best Way

7. Optimizing the whole. Must look at the bigger picture. Optimize the whole value stream, not just individual

functions or teams. Myth: Optimize By Decomposition

************ Software Modeling - UML [FOWLER-2002] Chapter 3, 4, 10 ************************************

A class diagram describes the types of objects in the System and the various kinds of static relationships that exist among them. Class diagrams also show the properties and operations of a Class and the constraints that apply to the way objects are connected. The UML uses the term feature as a general term that covers properties and operations of a Class. Properties represent structural features of a Class. Properties are a single concept, but they appear in two quite distinct notations: attributes and associations.

The attribute notation describes a property as a line of text within the class box itself.

An association is a solid line between two classes, directed from the source class to the target class. The name of the property goes at the target end of the association, together with its multiplicity. The target end of the association links to the class that is the type of the property.

The multiplicity of a property is an indication of how many objects may fill the property. The most common multiplicities you will see are

1 (An order must have exactly one customer.)

0..1 (A corporate customer may or may not have a single sales rep.)

*(A customer need not place an Order and there is no upper limit to the number of Orders a Customer may place-zero or more orders.)

A bidirectional association is a pair of properties that are linked together as inverses.

Operations are the actions that a class knows to carry out. An operation is something that is invoked on an object-the procedure declaration-whereas a method is the body of a procedure. Typical example of generalization involves the personal and corporate customers of a business. They have differences but also many similarities. The similarities can be placed in a general Customer class (the Supertype), with Personal Customer and Corporate Customer as subtypes. An important principle of using inheritance effectively is substitutability. I should be able to substitute a Corporate Customer within any Code that requires a Customer, and everything should work fine. Notes are comments in the diagrams. Notes can stand on their own, or they can be linked with a dashed line to the elements they are commenting

A dependency exists between two elements if changes to the definition of one element (the supplier) may cause changes to the other (the client).

Interaction diagrams describe how groups of objects collaborate in some behavior. The most common is the sequence diagram. A sequence diagram captures the behavior of a single scenario. The diagram shows a number of example objects and the messages that are passed between these objects within the use case. Centralized control, one participant does all the processing. Distributed control, processing is split among many participants, each doing a little bit.

Both loops and conditionals use interaction frames, which are ways of marking off a piece of a sequence diagram. If a caller sends a synchronous message, it must wait until the message is done, such as invoking a subroutine. If a caller sends an asynchronous message, it can continue processing and doesn't have to wait for a response.

You should use sequence diagrams when you want to look at the behavior of several objects within a single use case. Sequence diagrams are good at showing collaborations among the objects; they are not so good at precise definition of the behavior.

State machine diagrams are a familiar technique to describe the behavior of a System. In object-oriented approaches, you draw a State machine diagram for a single class to show the lifetime behavior of a single object. States can react to events without transition, using internal activities: putting the event, guard, and activity inside the state box itself. An internal activity is similar to a self-transition: a transition that loops back to the same state.

The entry activity is executed whenever you enter a states the exit activity, whenever you leave. However, internal activities do not trigger the entry and exit activities; that is the difference between internal activities and self-transitions.

Several states share common transitions and internal activities. In these Gases, you can make them substates and move the shared behavior into a superstate. States can be broken into several orthogonal state diagrams that run concurrently.

A state diagram can be implemented in three main ways: nested switch, state patterns and state tables. Stare diagrams are good at describing the behavior of an object across several use cases. Stare diagrams are not very good at describing behavior that involves a number of objects collaborating.