Lean [POPPENDIECK-2003] Chapter 1, 2 Software Modeling - UML [FOWLER-2002] Chapter 3, 4, 10

1. ************ 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

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

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

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

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