Oomd2015

KSP 1
Object-Oriented Modeling and
Design(MSE1003),MO2015
Prof.K.Sridhar Patnaik
Associate Professor
Dept of CSE,BIT,Mesra

OOMD(MSE1003):Course
Description
 Objective: To understand the UML and
orient towards OO methodology using
UML for modeling software systems.
 Prerequisite: Good understanding of
Object concepts
 -Sound knowledge of any OO Language
specially java.
 -Knowledge of S/w Engg Process.
KSP 2

Marks Distribution
 Three quiz‟s of 15 marks each(best of
two will be selected).
 Assignment test:10 marks
 End Sem:60 marks
 Qualifying
marks:50(Int.Assessment+End Sem)
KSP 3

KSP 4
Introduction
 It is a new way of thinking about problems
using models based on real world concepts.
 The basic construct is object which combines
both data structure and behavior in a single
entity.
 Rambaugh presents an object oriented
software development methodology, the
Object Modeling Technique (OMT) which
extends from analysis through design to
implementation.

KSP 5
 Analysis model is built to abstract essential
aspects of application domain which contains
objects found in application, their properties
and behavior.
 Then design model is made to describe and
optimize the implementation.
 Finally the design model is implemented in a
programming language, database or
hardware.
 Graphical notation is used for expressing
object-oriented models.

KSP 6
What is object-oriented?
 Software is organized as a collection of
discrete objects that incorporate both data
structure and behavior.
 In general it includes- identity, classification,
polymorphism and inheritance.
 Object Oriented Programming Language
= Object Based Programming Language(e.g.
'83 Ada and Modula-2)
+ Inheritance + Dynamic Binding

OO Modeling
 Civil engineers build many kinds of models.most
commonly , there are structural models that help
people visualize and specify parts of systems.
 Engineers might also build dynamic models for
instance to study the behaviour of a structure in the
presence of an earthquake.
 In s/w there are several ways to approach a model:
A)Algorithm Perspective
B)OO perspective
KSP 7

 Algorithm Perspective(AP): Traditional view of s/w
development takes an AP.The main building block of
all s/w is procedure or function.
 OO perspective:Main building block of all s/w systems
is object or class.
 Three tier architecture of building systems:
 User interface : find concrete objects, buttons, menu, dialog
boxes etc.
 Middleware: find object such as transactions & business
rule.
 Database: find concrete object tables (customer ,product,
order)
KSP 8

Importance of modeling
 If you want to build a dog house –basic tools, nails,
hammer, saw, tape etc. In few hours you end with a
house for dog and can do with no one else‟s help.
 If you want to build a house for your family with same
things….does it possible? It requires detailed planning,
some sketches etc.
 Modeling is a proven & well accepted engineering
techniques. We build architectural models of houses &
high rises to help their users visualize the final
product.
KSP 9

 Mathematical models in order to analyse the effects of
winds or earthquakes on our buildings.
 A model is simplification of reality, provides bluprints of
a system.
 A model may be structural, emphasizing the
organization of the system or it may be behavioral,
emphasizing the dynamics of the system.
KSP 10

Why do we model?
 We build model so that we can better understand the
system we are developing.
 Modeling concepts and not implementation.
 OO Development –way of thinking & not a prog.
Technique.
 OO Methodology: consists of building a model of an
application domain & then adding implementation
details to it during the design.
KSP 11

KSP 12
Identity
 Identity means that data is organized into
discrete, distinguishable entities called objects.
 Objects can be concrete or conceptual.
 In real world an object simply exist but within a
programming language each object has a
unique handle by which it can be uniquely
referenced.
 The handle can be implemented by address,
array index or unique value of an attribute.

KSP 13
Classification
 It means that objects with same data
structure (attribute) and behavior
(operations) are grouped into a class.
 A class is an abstraction that describes
important properties and ignores the
rest.

KSP 14
Polymorphism
 It means that the same operation (i.e.
action or transformation that the object
performs) may behave differently on
different classes.
 Specific implementation of an operation
by a certain class is called a method.

KSP 15
Inheritance
 It is the sharing of attributes and
operations among classes based on a
hierarchical relationship.
 Subclasses can be formed from broadly
defined class.
 Each subclass incorporates or inherits all
the properties of its super class and adds
its own unique properties.

KSP 16
Object-oriented development?
 The theme is the identification and
organization of application concepts rather
than final representation in a prog. Language.
 OOD approach encourages software
developers to work and think in terms of the
application domain through most of the
software engineering life cycle.
 It is a conceptual process independent of a
programming language until the final stage.

KSP 17
Object-oriented methodology
 Stages-
 Analysis
 System design
 Object design
 implementation

KSP 18
3 models
 Object model
 Dynamic model
 Functional model

KSP 19
Object model
 Describes basic structure of objects and
their relationship
 Contains object diagram
 Object diagram is a graph whose nodes
are object classes (Classes) and whose
arcs are relationships among classes.

KSP 20
Dynamic model
 Describes the aspects of a system that
change over time.
 It specifies and implement control
aspects of a system.
 Contains state diagram.
 State diagram is a graph whose nodes
are states and whose arcs are data-
flows.

KSP 21
Functional Model
 Describes data value transformation
within a system.
 Contains data flow diagram.
 Data Flow Diagram is a graph whose
nodes are processes and whose arcs
are data flows.

KSP 22
Object-Oriented concepts
 Abstraction
 Encapsulation
 Combining data and behavior
 Sharing
 Object structure, not Procedure Structure
 Synergy

KSP 23
Abstraction
 It consists of focusing on essential aspects of an entity and
ignoring accidental properties.
 The goal is to isolate those aspects that are important for some
purpose and suppress those aspects that are unimportant.
 Abstraction must always for some purpose because the purpose
determines what is and what is not important.
 Many different abstractions of same thing are possible,
depending on the purpose for which they are made.
 In building models, one must not search for absolute truth but for
adequacy for some purpose.
 A good model captures the crucial aspects of a problem and
omits the others.
 Focus on what an object is and does, not how to implement.

KSP 25
Encapsulation
 Information hiding
 Separating external aspects of an object
which are accessible to other objects,
from the internal implementation details
of the object, which are hidden from
other objects.
 The implementation of an object can be
changed without affecting the
applications that use it.

KSP 27
Synergy
 Identity, Classification, polymorphism
and inheritance can be used in isolation
but together they complement each other
synergistically.

KSP 28
Advantages of OOD……………
 Used in developing Compilers, Graphics, UI,
databases, Object oriented languages, CAD
systems, simulations, etc.
 Used to document existing programs that are
ill-structured and difficult to understand.
 Not reduces development time; it may take
more time than conventional development
because it is intended to promote future reuse
and reduce downstream errors and
maintenance.

KSP 29
Modeling
 A model is an abstraction of something
for the purpose of understanding it
before building it.
 The word model has 2 dimensions- a
view of a system ( object, dynamic or
functional) and a stage of development (
analysis, design or implementation)

KSP 30
 Purpose –
 Testing a physical entity before building
it
 Communication with customers
 Visualization
 Reduction of complexity

KSP 31
Object Modeling
 Captures static structure of a system-
 Objects in the system
 Attributes
 operations

KSP 32
Objects
 Define objects as a concept, abstraction
or thing with purposeful meaning.
 Two purpose of objects-
 Promote understanding of the real world
 Provide a practical basis for computer
implementation.
 All objects have identity and are
distinguishable.

KSP 34
Classes
 An object class describes a group of
objects with similar properties
(attributes), common behavior
(operations), common relationships to
other objects and common semantics.

KSP 35
Object diagram
 It provides a formal graphic notation for
modeling objects, classes and their
relationships to one another.
 Types-
 Class diagram
 Instance diagram

KSP 36
Class diagram
 A class diagram is a schema, pattern or
templates for describing many possible
instances of data.
 Describes classes.

KSP 37
Instance diagram
 Describes how a particular set of objects
relate to each other.
 Describes objects

KSP 38
Person
Class Diagram
(Person)
Ram
(Person)
Jai
(Person)
Instance Diagram

KSP 39
Attribute
 An attribute is a data value held by the
objects in a class.
 Each attribute name is unique within a
class.
 An attribute should be a pure data value,
not an object.

KSP 40
Object Modeling Notations
Person
name: string
age: integer
Class with Attributes
(Person)
Ram
24
(Person)
Jai
34
Objects with Values

KSP 41
Operations and Methods
 An operation is a function or transformation
that may be applied to or by objects in a class.
 All objects in a class share the same
operations.
 The same operation may apply to many
different classes.
 Such an operation is polymorphic i.e. the
same operation takes on different forms in
different classes.
 A method is the implementation of an
operation for a class.

KSP 42
Person
name
age
change-job
change-add
Person
name
age
change-job
change-add
Person
name
age
print
File
name
size
Operations

KSP 43
Links and Association
 Links and associations are the means for establishing
relationships among objects and classes.
 A link is a physical or conceptual connection between objects.
 A link is an instance of an association.
 An association describes a group of links with common structure
and semantics.
 All the links in an association connect objects from the same
classes.
 Association and links often appear as verbs in a problem
statement.
 An association describes a set of potential links in the same way
that a class describes a set of potential objects.

KSP 44
 Associations are bidirectional.
 In real, both directions of traversal are equally
meaningful and refer to same association.
 Associations are often implemented in
programming languages as pointers from one
object to another.
 A pointer is an attribute in one object that
contains an explicit reference to another
object.

KSP 45
 A link shows a relationship between two
or more objects.
 All connections among classes should
be modeled as association.
 One-to-one association
 Many-to-many association
 Ternary association

KSP 46
Country
name
City
name
Has-capital
(Country)
India
(City)
Delhi
Has-capital
Has-capital
Class Diagram
Instance Diagram
One-to-One Association and links

KSP 47
Line
name
Point
name
intersects
2+
(Line)
L1
(Line)
L2
(Line)
L3
(Point)
P1
(Line)
L4
(Line)
L5
(Point)
P2
Many-to-many Association and links
Class Diagram
Instance Diagram

KSP 48
Project Language
Person
(Project)
MIS
(Language)
.Net
(Project)
CAD
(Language)
C
(Person)
Jai
Ternary Association and Links

KSP 49
Multiplicity
 It specifies how many instances of one
class may relate to a single instance of an
associated class.
 In OMT solid ball -> zero or more
 Hollow ball -> optional (zero or one)
 Multiplicity depends upon assumptions
and how you define the boundaries of a
problem.

KSP 50
Link attributes
 An link attribute is a property of the links
in an association.

KSP 51
File User
Accessible By
Access permission
/etc/temp read Ram
/etc/temp read-write Mohan
/usr/lgn read-write Shyam
Link Attributes for a many-to-many association

KSP 52
Person
name
ssn
address
Company
Name
address
Works-for
Salary
Job-title
Performance rating
boss
manages
worker
Link attributes for one-to-many associations

KSP 53
Modeling an Association as a Class
 Each link becomes one instance of the
class.

KSP 54
User Workstation
Authorized on
Authorization
Priority
Privileges
Start session
Directory
Home directory
Modeling an association as a class

KSP 55
Role Names
 A role is one end of an association.
 A binary association has 2 roles, each of
which may have a role name.
 A role name is a name that uniquely identifies
one end of an association.
 Roles often appear as nouns in problem
descriptions.
 Use of role name is optional.
 Role names are necessary for associations
between two objects of the same class.

KSP 56
person company
employee employer
Works-for
Employee Employer
Ram TCS
Mohan Wipro
Role names for an association

KSP 57
ordering
 If order of objects required
 Indicated by writing “{ordered}” next to
multiplicity dot for the role.
window screen
{ordered}
Visible-on
Ordered sets in an association

KSP 58
Qualification
 It relates two classes and a qualifier.
 Qualifier is a special attribute that reduces the
effective multiplicity of an association.
 One-to-many or many-to-many may be
qualified that can be reduced to one-to-one. (
but not always)
 It distinguishes among the set of objects at the
many end of an association.
 A qualified association can also be considered
a form of ternary association.

KSP 59
Directory FileFile name
A qualified association
A directory plus a file name yields a file

KSP 60
Company office Person
organization
officer

KSP 61
Aggregation
 It is a part-of relationship
 It has transitivity property i.e. A is part of
B and B is part of C then A is part of C.
 It is anti symmetric i.e. if A is a part of B
then B is not a part of A.
 Aggregation is a special form of
association.

KSP 62
document paragraph sentence
Aggregation

KSP 63
Aggregation
 It is a form of association in which an
aggregate object is made of
components.
 Components are part of aggregate.
 Aggregate is inherently transitive i.e. an
aggregate has parts which may in turn
have parts.

KSP 64
Aggregation vs. Association
 Aggregation is a special form of
association.
 If two objects are tightly bound by a part-
whole relationship, it is an aggregation.
 If two objects are usually considered as
independent even though they may often
be linked, it is an association.

KSP 65
 A company is an aggregation of its
divisions which are in turn aggregations
of their departments; a company is
indirectly an aggregation of departments.
 A company is not an aggregation of its
employees since the company and
person are independent objects of equal
structure and status.

KSP 66
company division department
person
Work for
Aggregation and Association

KSP 67
Generalization
 It is a relationship between base class
and sub class.
 It is “is-a” relationship because each
instance of a sub class is an instance of
super class as well.

KSP 68
Figure
Color
Pos
Thickness
Move
Select
Display
rotate
0 D 1 D 2 D
Point Line Arc Spline circlePolygon
Inheritance for graphic figure

KSP 69
Aggregation vs. Generalization
 Aggregation relates instances.
 Two distinct objects are involved; one of them
is a part of the other.
 Generalization relates classes.
 Aggregation is often called “a part of”
relationship; generalization is often called “a
kind-of” or “is-a” relationship.
 Aggregation is sometimes called an “and
relationship” and generalization refers to “or
relationship”

KSP 70
lamp
base cover switch wiring
incandescentfluorescent
part4part3part2part1
Aggregation and generalization

KSP 71
 Aggregation can be fixed, variable or
recursive.
 A fixed aggregate has a fixed structure;
the number and types of sub parts are
predefined e.g. lamp.
 A variable aggregation has a finite
number of levels but number of parts
may vary e.g. company.

KSP 72
 A recursive aggregation contains directly
or indirectly an instance of the same kind
of aggregate; the number of potential
levels is unlimited e.g. computer
program.

KSP 73
 Simple Statement:
x=i;
 Block(combination of more than one simple statements):
++i;
x=i;
 Compound Statement(single statement combines work of multiple
statement optionally blocks):
x=++i;
program
block
Compound
statement
Simple
statement
Recursive aggregate

KSP 74
Propagation of operations
 Propagation (triggering) is automatic
application of an operation to a network
of objects when the operation is applied
to some starting object.
 E.g. moving an aggregation moves its
parts; the move operation propagates to
the parts.

KSP 75
 A person owns multiple documents.
Each document is composed of
paragraphs that are in turn composed of
characters. The copy operation
propagates from documents to
paragraphs to characters. Copying a
paragraph copies all the characters in it.
 The operation does not propagate in
reverse direction.

KSP 76
 Propagation can be possible for save,
destroy, print and lock.
Person Document
copy
Paragraph
copy
Character
copy
owns
copy copy
Propagation of operations

KSP 77
Abstract classes
 An abstract class is a class that has no
direct instances but whose descendent
classes have direct instances.
 A concrete class is a class that is
instantiable i.e. it can have direct
instances.
 A concrete class may have abstract
subclasses but they must have concrete
descendents.

KSP 78
 only concrete classes may be leaf
classes in the inheritance tree.

KSP 79
Abstract & concrete class
class
concrete abstractinstance
Leaf classNon leaf class
subclass
1+ 1+
subclass
Has subclasses
Has subclasses
superclass
superclass
Direct
instances

KSP 80
 Abstract classes organize features common to
several classes
 Abstract classes are frequently used to define
methods to be inherited by subclasses.
 An abstract class can define methods to be
inherited by subclasses.
 An abstract operation defines the form of an
operation for which each concrete subclass
must provide its own implementation.

KSP 81
 Abstract class & abstract operation
Employee
Earning
Pay {abstract}
SLRD Employee
Earning
pay
HNRY Employee
Earning
pay
HRLY Employee
Earning
pay

KSP 82
Overriding operations
 Reasons to use overriding-
 For extension
 For restriction
 For optimization
 For convenience

KSP 83
 Extension
The new operation is same as inherited except it adds some
behavior usually affecting new attributes of the subclass.
 Restriction
The new operation restricts the inherited.
 Optimization
The new method must have the same external protocol
(prototype) and results as the old one but its internal
representation and algorithm may differ completely.
 Convenience
The new class is made a subclass of the existing class and
overrides the methods that are inconvenient.

KSP 84
Multiple inheritance
 It permits to have more than one super class
and to inherit features from all parents.
 A class with more than one super class is
called a join class.
 A feature from the ancestor class found along
more than one path is inherited only once.
 Conflicts among parallel definitions create
ambiguities that must be resolved in
implementation.

KSP 85
vehicle
WatervehicleLandvehicle
boatamphibiousvehiclecar
Multiple inheritance from overlapping classes
[ join class ]
Overlapping Classes

KSP 86
 A hollow triangle indicates disjoint
subclasses while a solid triangle
indicates overlapping subclasses.

KSP 87
Metadata
 Metadata is data that describes other
data.
 The definition of a class is metadata.
 Models are metadata since they describe
the things being modeled.
 RDBMS uses metadata.

KSP 88
 A class describes a set of instances of a
given form.
 Instantiation relates a class to its
instances.
 The dotted arrows connect the instances
to the class.
 It is also useful for documenting
examples and test cases.

KSP 89
Person
Name
Age
weight
(Person)
Name=ABC
Age=40
Weight=40
(Person)
Name=XYZ
Age=29
Weight=70
Notation for instantiation

KSP 90
Class descriptors
 Classes are meta objects and not real world objects.
 Class descriptors have features and they have their
own classes which are called meta classes.
 A class attribute describes a value common to an
entire class of objects rather than data particular to
each instance.
 Class attributes are useful for storing default
information for creating new objects or summary
information about instances of the class.
 A class operation is an operation on the class itself.
 The most common is to create new instances.
 Operations on class structure are class operations.

KSP 91
Class descriptors
Window
Size:rectangle
Visibility:boolean
Default_size:rectangle
Display
New_window
Highest_priority_window

KSP 92
Candidate keys
 A candidate key is a minimal set of
attributes that uniquely identifies an
object or link.
 A class may have one or more candidate
keys each of which may have different
combinations and numbers of attributes.
 Each candidate key constrains the
instances in a class.
 Notation is {}

KSP 93
constraints
 These are functional relation between
entities of an object model.
 Entity includes objects, classes,
attributes, links and associations.
 A constraint restricts the values that
entities can assume.
 Simple constraints may be placed in
object models and complex may be in
functional model.

KSP 94
Employee
salary
boss
{ salary < = boss.salary }
Window
Length
width
{ 0.8 <= length / width < = 1.5 }
Constraints on objects

KSP 95
General constraints
 It must be expressed with natural
languages or equations.
 Draw a dotted line between classes
involved in the constraint and specify the
details with comments in braces.
Person Committee
Member_of
Chair_of
{subset }

KSP 96
Derived objects, links and attributes
 The notation for a derived entity is a
slash or diagonal line on the corner of a
class box, on an association line or in
front of an attribute.
 Show the constraint that determines the
derived value. (optional)
Person
Birthdate
/age
Current date
{ age = currentdate – birthdate }

KSP 97
Homomorphism
 A mapping between mathematical structures of the same type (eg
groups or rings) that preserves the structure.
 similarity of form
 Homos = same & morphe = structure
 E.g. in a parts catalog for a automobile, a catalog item may
contain other catalog items.
 Each catalog item is specified by a model number that
corresponds to number of individual manufactured items, each
with its own serial number.
 The individual items are also composed of sub items.
 The structure of each item‟s parts has the same form as the
catalog item‟s parts.
 Thus the “contains” aggregation on catalog items is a
homomorphism of the “contains” aggregation on physical items.

KSP 98
Homomorphism
 It maps between two associations.
catalogItem
Model#
Item
Sl#
contains
containsMaps
Describes
{ item 1 contains item 2 => item1.model contains item2.model }
Homomorphism for a parts catalog

KSP 99
 In general, a homomorphism involves 4
relationships among 4 classes.
 The homomorphism maps links of one general
association {u} into links of another general
association {t} as a many-to-one mapping.
 Two instantiation relationships map elements
of one class into another:
 r is a many-to-one mapping from class B to A and
 s is a many-to-one mapping from class D to C.

KSP 100
A
C
B
D
r
s
t u
{u ( b, d)=>t ( b.r, d.s ) }
General Homomorphism

KSP 101
 In general where t is on a single class
and u is on a single class then A=C, B=D
and r=s.
 Homomorphism is a special type of
relationship between relationships.

KSP 102
Dynamic Modeling
 First examine the system at a single moment of time.
 Then examine changes to objects and their
relationships over time.
 Those aspects of a system that are concerned with
time and changes are dynamic model, in contrast with
static or object model.
 Control is the aspect of a system that describes the
sequences of operations that occur in response to
external stimuli without considering what the operation
do, what they operate on, and how they are
implemented.

KSP 103
concepts
 Events – represent external stimuli
 States – values of objects
 State diagram

KSP 104
Events
 It is something that happens at a point in time
 One event may logically precede or follow
another or the two events may be unrelated.
 The two events are casually related.
 The two events are casually unrelated are said
to be concurrent i.e. they have no effect on
each other.
 In modeling a system we do not establish an
ordering between concurrent events because
they can occur at any order.

KSP 105
 An event is a one-way transmission of
information from one object to another.
 In real world, all objects exist
concurrently.
 An object sending an event to another
object may expect a reply but the reply is
a separate event under the control of the
second object which may or may not
choose to send it.

KSP 106
 Every event is a unique occurrence, but we group
them into event classes and give each event class a
name to indicate common structure and behavior.
 This structure is hierarchical as class structure.
 E.g. flight 123 departs from Delhi and flight 321
departs from Rome are instances of event class
airplane flight departs having attributes airline flight no,
city.
 The time at which an event occurs is an implicit
attribute of all events.

KSP 107
 An event conveys information from one
object to another.
 Some classes of events may be simply
signals that something has occurred
while other convey data values i.e.
attributes.
 Showing attributes is optional.

KSP 108
Airplane flight departs (airline, flight#, city)
Mouse button pushed (button, location)
Input string entered (text)
Phone receiver lifted
Digit dialed (digit)
Event classes and attributes

KSP 109
Scenarios and event traces
 A scenario is a sequence of events that occurs
during one particular execution of a system.
 The scope of a scenario can vary; it may
include all events in the system or it may
include only those events generated by certain
objects in the system.
 It can be the historical record of executing a
system or a thought experiment of executing a
proposed system.

KSP 110
Caller lifts receiver
Dial tone begins
Caller dials digit (5)
Dial tone ends
Called phone begins ringing
Ringing tone appears in calling phone
Called party answers
Called phone stops ringing
Ringing tone disappears in calling phone
Phones are connected
Called party hangs up
Phones are disconnected
Caller hangs up
Scenario for phone call

KSP 111
 The next step after writing scenario is to identify the
sender and receiver objects of each event.
 The sequence of events and the objects exchanging
events are shown in event trace diagram.
 This diagram shows each object as a vertical line and
each event as a horizontal arrow from the sender to
receiver objects.
 Time increases from top to bottom.
 Sequences of events are shown not their exact timing.

KSP 112
Event trace for phone call
Caller phone line callee
Caller lifts receiver
Dial tone begins
Dial tone ends
Called phone begins ringing phone rings
answer phone
ringing stops ringing stops
phones are connected phones connected
Callee hangs up
disconnected disconnected
Caller hangs up

KSP 113
States
 It is an abstraction of the attribute values and links of
an object.
 Set of values are grouped together into a state
according to properties that affect the gross behavior
of the object e.g. the state of bank is either solvent or
insolvent whether its assets are greater than liabilities.
 A state specifies the response of the object to input
events.
 Response is same for all values within the same state
and may be different for values in different states.
 Response of an object to an event may include an
action or change of states by the object.

KSP 114
 A state has duration
 An event separates two states and a
state separates two events.
 In defining states we ignore those
attributes that do not affect the behavior
of the objects.

KSP 115
State diagram
 It relates events and states.
 When an event is received, the next
state depends on the current state as
well as the event; a change of state
caused by an event is called a transition.
 State diagram is a graph whose nodes
are states and whose directed arcs are
transitions labeled by event names.

KSP 116
idle
Timed- out
disconnected
Busy tone
Fast busy tone
Dial tone
dialing
connecting
ringing
connected
Recorded message
On-hook
On-hook
Off-hook
Digit(n)
Invalid no
valid
routed
Called phone answers
Called phone hangs up
Trunk busy
Num busy
State diagram for phone line

KSP 117
 A state diagram describes the behavior of a
single class.
 Since all instances of a class have same
behavior they all share the same state
diagram as they all share the same class
features.
 But as each object has its own attribute values
so each object has its own state.
 Each object is independent of the other
objects and proceeds as its own pace.

KSP 118
Conditions
 A condition is a Boolean function of
object values.
 When Ram goes out in morning( event),
if the temperature is below freezing(
condition), then he puts on his gloves
(next state).
 Notation is [condition]

KSP 119
Operations
 An activity is an operation that takes time to complete.
 An activity is associated with a state.
 Notation “do:A” within a state box indicates that activity A starts
on entry to the state and stops on exit.
 An action is an instantaneous operation.
 An operation is associated with an event.
 An action represents an operation whose duration is insignificant
compared to the state diagram e.g. disconnect phone line might
be an action in response to an on_hook event for phone line.
 Actions can also represent internal control operations such as
setting attributes or generating other events.
 The notation for an action is (“/”) and the name of action, following
the name of the event that causes it.

KSP 120
Action for pop-up menu
idle Menu visible
Right button down/display menu
Right button up/erase menu
Cursor moved/highlight menu item

KSP 121
State1
do:activity1
State2
do:activity1
Event1 (attributes)[condition1]/action1

KSP 122
Sate generalization
 A nested state diagram is a form of
generalization on states.
 Generalization is “or-relation”.
 States may have sub states that inherit
the transitions of their super states just
as classes have subclasses that inherit
the attributes and operations of their
super classes.

KSP 123
Aggregation and its concurrent state
diagram
Car
Ignition Transmission Brake Accelerator
Ignition
off starting on
Turn key to
start[Transmission
in Neutral] Released Key
Turn key off

KSP 124
Sate of car transmission with
generalization
Transmission
Neutral Reverse
Push R
Push N
Forward
First Second Third
upshift upshift
downshift downshift
Stop
Push N Push F

KSP 125
Accelerator
Off On
press
Release
Accelerator
Off
Brake
Off On
press
Release

KSP 127
 It specifies the results of a computation
without specifying how or when they are
computed.
 It specifies the meaning of operations in
object model and actions in dynamic
model as well as constraints in object
model.
 Functional model exists where
transformation is a key factor.

Inheritance Vs Deligation
public class Weapon
{
private String name; private int weight; private int damage;
public Weapon(String name, int weight)
{ this.name = name; this.weight = weight; }
public int getDamage()
{ return damage * 100; }
public void setDamage(int damage)
{ this.damage = damage; }
}
KSP 128

public class Sword extends Weapon
{
private int sharpness = 100; public int getSharpness()
{ return sharpness; }
public void setSharpness(int sharpness)
{ this.sharpness = sharpness; }
public int getDamage()
{ return damage * sharpness;
}
}
KSP 129

public class Bow extends Weapon
{ private int arrows; public int getArrows()
{ return arrows; }
public void setArrows(int arrows)
{ this.arrows = arrows; }
}
KSP 130

Both of them are ways of extending and reusing a (super)class. But
there is of course a major difference.
By using Inheritance , a subclass inherits all of the variables and all
of the methods defined in the superclass. While by delegation you
write another class with additional functionality that uses instances of
the original class to provide the original functionality.
In other words, when using inheritance the subclass is simply a
subclass of the superclass with some additional functionality, while
when using delegation, your delegating class contains a reference to
an instance of the superclass and delegates the method calls to the
superclass.
KSP 131

So, Bow and Sword inherit the superclass Weapon, giving them
exactly the same constructor and methods as the weapon object,
including their own extra functionality.
So you can still call the method 'setDamage' on the Sword and Bow
object as well as the 'getDamage' method, even though Sword
object overrides this method with its own implementation. And you
still can create a bow with 20 arrows by calling:
Bow myLongBow = new Bow("longbow", 20);
myLongBow.setDamage(40);
myLongBow.setArrows(20);
So this is all about inheritance. Now for delegation. Delegation would
come in handy if we also had a MagicalObject class which provides
magical features.
KSP 132

public class MagicalObject
{ private int mana;
public MagicalObject()
{ mana = 100; }
public int getMana()
{ return mana; }
public void setMana(int mana)
{ this.mana = mana; }
public void doSpell() { .... // Does the actual magic } }
KSP 133

And that's where delegation comes into place. Java, as
opposed to some other Object Oriented languages, does
not allow multiple inheritance.
So if you wanted to create a magical sword, you could
not just simply extend both the Weapon class and the
MagicalObject class. One way to go to still do something
like multiple inheritance is by making use of delegation.
To do this, you create an instance of the delegated
object within your object and delegate all methods to that
instance. So for a magical bow object, we'd end up with
something like this:
KSP 134

public class MagicalBow extends Bow
{ private MagicalObject _magicalObject; // The delegation
instance;
public MagicalBow(String name, int damage)
{ super(name, damage); _
magicalObject = new MagicalObject(); }
public int getMana()
{ return _magicalObject.getMana(); // Delegates the method call
} public void setMana(int mana)
{ _magicalObject.setMana(mana); // Delegates the method call
} public void doSpell()
{ _magicalObject.doSpell(); // Delegates the method call } }
KSP 135

Note that the methods that we want to use
from the MagicalObject class also need to
be implemented in the MagicalBow class,
but that all the calls are delegated to the
instance of the MagicalObject class that's
defined in the MagicalBow instance. So
that's what we call delegation.
KSP 136

Also note that if one would implement such
a thing as above and would choose for this
approach, I'd recommend to also make
use of a MagicalObject interface and let
both the MagicalObject and the
MagicalBow implement this interface. That
way you can always force the MagicalBow
to implement all methods that are declared
in the interface.
KSP 137

 First lets create an Interface for our Delegates, since Delegates can be interchanged they all must implement
the same interface:
 public interface ISoundBehaviour
 {

 public void makeSound();
 }
 public class MeowSound implements ISoundBehaviour
 {
 public void makeSound() {
 System.out.println("Meow");
 }
 }
 public class RoarSound implements ISoundBehaviour
 {
 public void makeSound() {
 System.out.println("Roar!");
 }
 }
KSP 139

Now lets create a cat class which uses the MeowSound per default:
public class Cat {
private ISoundBehaviour sound = new MeowSound();
public void makeSound()
{ this.sound.makeSound();
}
public void setSoundBehaviour(ISoundBehaviour newsound)
{ this.sound = newsound;
}
}
KSP 140

Finally a Main class to test our delegation pattern:
public class Main
{ public static void main(String args[])
{ Cat c = new Cat(); // Delegation
c.makeSound(); // Output: Meow
// now to change the sound it makes
ISoundBehaviour newsound = new RoarSound();
c.setSoundBehaviour(newsound); // Delegation
c.makeSound(); // Output: Roar!
}
}
KSP 141

Inheritance Vs Deligation
KSP 142
Employee
empid:int
getEmpid():int
setEmpid(empid:int):void
Architect
design():void
Developer
develop():void
ProjectManager
manage():void
Tester
test():void


 KSP 143
Employee
empid:int
getEmpid():int
setEmpid(empid:int):void
Architect
design():void
Developer
develop():void
ProjectManager
manage():void
Tester
test():void
ADP
design()
develop()
manage()

Workarounds
 Dealing with lack of multiple inheritance is really an implementation
issue, but early restructuring of a model is often the easiest way to work
around its absence.
 1)Multiple Inheritance using Delegation.
 2)Multiple Inheritance using inheritance and Delegation.
 3)Multiple inheritance using nested generalization.
KSP 144

KSP 145
DFD
 It shows the functional relationships of the
values computed by a system, including input
values, output values and internal data stores.
 A DFD is a graph showing the flow of data
values from their sources in objects through
processes that transform them to their
destinations in other objects.
 It does not show control information like time,
etc.

KSP 146
Elements of DFD
 Processes -> Transform data
 Data flow -> move data
 Actor ->objects that produce and consume
data.
 Data store -> objects that store data
passively.
ProcessName
actorName
Data_storeName
Information/operation
that modify stored data
Information received from
stored data

KSP 147
Data Stores
 It is a passive object within the graph that
stores data.
 It does not generate any operation but merely
responds to requests to store and access
data.
 It is drawn as a pair of parallel lines containing
the name of the store.
 Input arrows indicate information or operations
that modify the stored data.
 Output arrows indicate information retrieved
from data store.
 In general data store is implemented as a file.

KSP 148
Data store for temprature readings..
Readings
Max temp
Min temp

KSP 149
Data store for bank account
Customer
withdrawl
-
Account
balance
Double headed arrow indicates that balance is both an i/p and o/p of
Subtract operation.

KSP 150
Data store for price list for items
Price list
Item_name
cost
Find costItem name cost

KSP 151
 A data flow that generates an object
used as the target of another operation is
indicated by a hollow triangle at the end
of data flow.
Bank Accountselectaccounts
Customer
name
update
request
balance
( i/p and o/p)
Selection with an object as result

KSP 152
 Creation of new object
Create account Bank
account
AccountCustomer
Name, deposit
account

KSP 153
Nested DFD
 The nesting of a diagram is also called
leveling.
 A process can be expanded into another
DFD.

KSP 154
Control Flows
 A data flow diagram shows all possible
computation paths for values.
 Decisions and sequencing are control
issues that are part of dynamic model.
 It is sometime useful to include it in
functional model so that they can not be
forgotten. This is done by including
control flows in DFD.

KSP 155
 A control flow is a Boolean value that
affects whether a process is evaluated or
not.
 It is shown by a dotted line from a
process producing a Boolean value to
the process being controlled.

KSP 156
customer update
verify
Account
password
amount
cash
Coded password
Password
OK
balance

KSP 157
Specifying Operations
 Each operation may be specified as-
 Mathematical functions
 Table of input and output values.
 Equations
 Pre and post conditions
 Decisions tables
 Pseudo code, etc

KSP 158
 Specification of an operation includes a
signature and a transformation.
 Signature defines the interface to the
operation i.e. arguments, value returns.
 The transformation defines the effect of
an operation i.e. the output values and
the side effects of the operation on its
operand objects.

KSP 159
 Operations can be divided into three
parts-
 Queries
 Actions
 Activities

KSP 160
Query
 A query is an operation that has no side
effects on externally visible state of any object.
 An action is a transformation that has side
effects on the target object or other objects in
the system reachable from the target object.
 Actions can be defined by mathematical
equations, decision trees, decision tables, etc.

KSP 161
Activity
 It is an operation to or by an object that
has duration in time.
 It has inherently side effects because of
its extension in time.
 Activity only make sense for actors.

KSP 162
constraints
 It shows the relationship between two objects at the
same time (frequency and wavelength )Or between
different values of the same object at different times
(no of outstanding shares of mutual fund).
 It can appear in each model.
 Object constraints specify that some objects depend
entirely or partially on other objects.
 Dynamic constraints specify relationships among the
states or events of different objects.
 Functional constraints specify restrictions on
operations.
 A constraint between values of an object over time is
called as invariant i.e. it specifies that some functions
of values remain constant over time.

KSP 163
FM Vs OM & DM
 FM shows what has to be done by a
system.
 The object model shows the “doers”- the
object.
 DM shows the sequences in which the
operations are performed.
 The three models come together in the
implementation of methods.
 FM is a guide to the methods.

KSP 164
 A process is usually implemented as a
method.
 Actors and data stores are objects in the
object model.
 Data flows are values in object model.

KSP 165
 Relative to functional model the object
model shows the structure of the actors,
data store and flows.
 Relative to functional model the dynamic
model shows the sequence in which
processes are performed.

KSP 166
 Relative to object model the functional
model shows the operations on classes
and the arguments of each operations.
 Relative to object model the dynamic
model shows the states of each object
and the operations that are performed as
it receives events and changes state.

KSP 167
 Relative to dynamic model the functional
model shows the definition of actions
and activities that are undefined with
dynamic model.
 Relative to dynamic model the object
model shows what changes state and
undergoes operations.

KSP 168
Structured analysis/structured
design (SA/SD)
 During analysis DFD, data dictionary,
state transition diagram and ER diagram
are used to logically describe a system.
 In the design phase, details are added to
the analysis models and the DFDs are
converted into structure chart describing
program language code.

KSP 169
Data dictionary
 A paragraph is written that precisely
describe each class.
 Describe the scope of class, any
assumptions, restrictions.
 It also describes associations, attributes
and operations.

KSP 170
SA/SD and OMT
 Both support object, dynamic and functional
model for a system.
 OMT designs are dominated by object
modeling while SA/SD stresses on functional
decomposition.
 SA/SD organizes a system around procedures
while OMT organizes a system around real
world objects or conceptual objects that exist
in user‟s view of the world.

KSP 171
 SA/SD is useful for problems where functions
are more important and complex than data.
 SA/SD design has a clearly defined system
boundary across which the software
procedures must communicate with the real
world. so it can be difficult to extend a SA/SD
design to a new boundary.
 It is much easier to extend object oriented
design; one merely design adds objects and
relationships.

KSP 172
 In SA/SD the decomposition of a process into
sub process is somewhat arbitrary.
 Different people will produce different
decomposition.
 In OMT the decomposition is based on objects
in problem domain, so developers of different
programs in same domain tend to discover
similar objects. This increases reusability of
components from one project to the next.

KSP 173
 An OMT approach better integrates
database with programming code.
 Object oriented database may improve
the situation.
 In contrast, SA/SD is inherently awkward
at dealing with databases. It is difficult to
merge programming code organized
about functions with database organized
with data.

KSP 174
Reasons to use SA/SD
 Programmers have tended to think in
terms of functions so data flow based
method have been easier to learn.
 Another reason is historical; SA/SD was
one of the first well-thought-out formal
approach to software and system
development.

KSP 175
Jackson Structured Development
(JSD )
 Developed by Michael Jackson
 Popular in Europe.
 It does not distinguish between analysis and
design rather lumps both phases together as
specification.
 It first determine “what” and then “how”
 It is useful for application where timing is
important.
 It is less graphical oriented than SA/SD and
OMT.

KSP 176
 JSD model describes the real world in
terms of entities, action and ordering of
actions.
 Entities usually appear as nouns in
requirements statements and actions
appear as verbs.
 JSD consists of six sequential steps-

KSP 177
 Entity action
 Entity structure
 Initial model
 Function
 System timing
 implementation

KSP 178
Entity action
 The software developer lists entities and
actions for part of real world.
 The purpose is to guide the choice of
entities and actions for overall system.
 The input to this step is requirement
statement
 The output is list of entities and actions.

KSP 179
 The entity structure step partially orders
the actions of each entity by time.
 The initial model step states how the real
world connects to the abstract model.
 The function step uses pseudo code to
state outputs of actions.
 At the end of this step the developer has
a complete specification of required
system.

KSP 180
 The system timing step considers how
much the model is permitted to gap the
real world.
 The implementation step focuses on the
problems of processes scheduling and
allocates processors to processes.

KSP 181
JSD and OMT
 JSD is more obscure than data flow and
object-oriented approaches.
 One reason for this is its reliance on
pseudo codes; graphical models are
easier to understand.
 It is also complex because it was
specifically designed to handle difficult
real time problems

KSP 182
JSD is useful in applications like-
 More emphasis on actions and less on
attributes.
 Where processed must synchronize with each
other
 Real time software
 Microcode. It is thorough and makes no
assumptions about the availability of an
operating system and considers synchronized
processing and timing.
 Programming parallel computers.

KSP 183
JSD is ill suited for applications like-
 High level analysis. It is ineffective at
abstraction and simplification.
 Databses. It is biased towards actions
and away from entities and attributes. It
is poor technique for database design.
 Conventional software running under an
operating system. Its abstraction of
hundreds or thousands of processes is
confusing and unnecessary.

Methodology Preview
OMT as a software engineering methodology: SE is a process for the
organized production of software, using a collection of predefined
techniques and notational conventions.
A methodology is usually presented as a series of steps, with techniques
and notation associated with each step.
OMT supports the entire s/w life cycle.
Analysis: Input is problem statement and output is the formal models
System Design: Overall architecture of the system. Using the object
model as a guide ,the system is organized into subsystems.
Object Design: During object design there is a shift in emphasis from
application concepts towards computer concepts.
KSP 184

Impact of OOA
Shifting of development effort into analysis: The resulting design is
cleaner and more adaptable, future changes are much easier.
Emphasis on DS before function: This change of emphasis gives the
development process a more stable base and allows the use of a single
unifying s/w concept throughout the process:concept of an object.
All other concepts :-functions ,relationships, and events, are organized
around objects so that information recorded during analysis is not lost or
transformed when design and implementation take place.
The DSs of an application and the relationships between them are much
less vulnerable to changing requirements than the operations performed on
the data.
Organizing a system around objects rather than around functions gives the
development process a stability that is lacking in function–oriented
approaches.
KSP 185

Seamless development process: The object model developed during
analysis is used for design and implementation, and work is channeled into
refining the model at progressively more detailed levels rather than
converting from one representation into another.
The process is seamless because there are no discontinuities in which a
notation at one phase is replaced by a different notation at another phase.
Iterative rather than sequential: Although the description of the object
OMT is of necessarily linear, the actual development process is iterative.
KSP 186

Analysis
Overview of Analysis Process
Problem Statement
ATM: Case study
KSP 187

ATM:case study
 The software to be designed will control a simulated automated teller machine (ATM) having a
magnetic stripe reader for reading an ATM card, a customer console (keyboard and display)
for interaction with the customer, a slot for depositing envelopes, a dispenser for cash (in
multiples of $20), a printer for printing customer receipts, and a key-operated switch to allow
an operator to start or stop the machine. The ATM will communicate with the bank's computer
over an appropriate communication link. (The software on the latter is not part of the
requirements for this problem.)
 The ATM will service one customer at a time. A customer will be required to insert an ATM
card and enter a personal identification number (PIN) - both of which will be sent to the bank
for validation as part of each transaction. The customer will then be able to perform one or
more transactions. The card will be retained in the machine until the customer indicates that
he/she desires no further transactions, at which point it will be returned - except as noted
below.
 The ATM must be able to provide the following services to the customer:
1)A customer must be able to make a cash withdrawal from any suitable account linked to
the card, in multiples of $20.00. Approval must be obtained from the bank before cash is
dispensed.
.
KSP 188

2)A customer must be able to make a deposit to any account linked to the card, consisting
of cash and/or checks in an envelope. The customer will enter the amount of the deposit
into the ATM, subject to manual verification when the envelope is removed from the
machine by an operator. Approval must be obtained from the bank before physically
accepting the envelope
3)A customer must be able to make a transfer of money between any two accounts linked
to the card.
4) A customer must be able to make a balance inquiry of any account linked to the card.
 A customer must be able to abort a transaction in progress by pressing the Cancel key instead
of responding to a request from the machine.
 The ATM will communicate each transaction to the bank and obtain verification that it was
allowed by the bank. Ordinarily, a transaction will be considered complete by the bank once it
has been approved. In the case of a deposit, a second message will be sent to the bank
indicating that the customer has deposited the envelope. (If the customer fails to deposit the
envelope within the timeout period, or presses cancel instead, no second message will be
sent to the bank and the deposit will not be credited to the customer.)
KSP 189

 If the bank determines that the customer's PIN is invalid, the customer will be required to re-
enter the PIN before a transaction can proceed. If the customer is unable to successfully enter
the PIN after three tries, the card will be permanently retained by the machine, and the
customer will have to contact the bank to get it back.
 If a transaction fails for any reason other than an invalid PIN, the ATM will display an
explanation of the problem, and will then ask the customer whether he/she wants to do
another transaction.
 The ATM will provide the customer with a printed receipt for each successful transaction,
showing the date, time, machine location, type of transaction, account(s), amount, and ending
and available balance(s) of the affected account ("to" account for transfers).
KSP 190

 The ATM will have a key-operated switch that will allow an operator to start and stop the
servicing of customers. After turning the switch to the "on" position, the operator will be
required to verify and enter the total cash on hand. The machine can only be turned off when it
is not servicing a customer. When the switch is moved to the "off" position, the machine will
shut down, so that the operator may remove deposit envelopes and reload the machine with
cash, blank receipts, etc.
 The ATM will also maintain an internal log of transactions to facilitate resolving ambiguities
arising from a hardware failure in the middle of a transaction. Entries will be made in the log
when the ATM is started up and shut down, for each message sent to the Bank (along with the
response back, if one is expected), for the dispensing of cash, and for the receiving of an
envelope. Log entries may contain card numbers and dollar amounts, but for security will
never contain a PIN.
KSP 191

Object Modeling
The following steps are performed in constructing an OM:
1)Identify objects and class
2)Prepare a data dictionary
3)Identify associations(including aggregations) between
objects.
4)Identify attributes of objects and links
5)Organize and simplify object classes using inheritance.
6)Verify that access paths exists for likely queries.
7)Iterate and refine the model
8)Group classes into modules
KSP 195

Identifying Assosiations
1)Association often corresponds to verb phrases. These include physical
location (next to, part of, contained in), directed action
(drives),communication (talks to),ownership (has, part of) or satisfaction of
some condition(works for, married to, manages).
2)Extract all the candidates from the problem statement and get them down
on paper first; don‟t try to refine things too early.
3)Don‟t spend much time trying to distinguish between association and
aggregation.
KSP 196

Associations from ATM problem statement
Verb Phrases
1)Banking network includes cashiers and ATMs.
2)Consortium shares ATMs.
3) Bank provides bank computer.
4)Bank computer maintains a/cs
5)Bank computer processes transaction against a/c.
6)Bank owns cashier station.
7)Cashier station communicates with bank computer.
8)Cashier enters transaction for a/c.
9)ATMs communicate with central computer about transaction.
10)Central computer clears transaction with bank.
11)ATM accepts cash card.
12)ATM interacts with user.
13)ATM dispenses cash.
14)ATM prints receipt.
KSP 197

KSP 198
15) System handles concurrent access.
16)Banks provides s/w
17)Cost apportioned to bank.
Implicit verb phrases
18)Consortium consists of bank
19)Bank holds a/c
20)Consortium owns central computer.
21)System provides record keeping.
22)System provides security.
23)Customer have cash card.
Knowledge of problem domain
24)Cash card access a/cs
25)Bank employs cashiers

Keeping the right associations
1)Association between eliminated classes: If one of the classes in the association
has been eliminated , then the association must be eliminated or restated in terms of
other classes.
We can eliminate:1)Banking network includes cashiers and ATMs.
17)Cost apportioned to bank.
14)ATM prints receipt.
13)ATM dispenses cash.
21)System provides record keeping.
22)System provides security.
16)Banks provides s/w
KSP 199

2)Irrelevant or implementation associations: eliminate any association that are
outside the problem domain or deal with implementation constructs.
Eliminate:
15) System handles concurrent access.(an implementation concept. Real world
objects are inherently concurrent ;it is the implementation of the access algorithm that
is required to be concurrent.
3)Actions: An association should describe a structural property of the application
domain, not a transient event .
Eliminate:
11)ATM accepts cash card.
12)ATM interacts with user.
Sometimes, a requirement expressed as an action implies an underlying
structural relationship and should be rephrased accordingly.
10)Central computer clears transaction with bank.describes an action that implies
the structural realtionship
10)Central computer communicates with bank
KSP 200

4)Ternary associations:Most associations between three or more classes can be
decomposed into binary associations or phrased as qualified association.
8)Cashier enters transaction for a/c. can be broken into Cashier enters transaction
and Transaction concerns a/c.
5)Bank computer processes transaction against a/c. can be broken similarly.
9)ATMs communicate with central computer about transaction. can be broken
similarly.
9)ATMs communicate with central computer and Transaction entered on ATM
5)Derived Association: Omit associations that can be defined in terms of other
associations because they are redundant.
Ex. Grand parent of can be defined in terms of a pair of Parent of associations.
Also omit associations defined by conditions on object attributes.
Ex.Younger than expresses a condition on the birth dates of two persons,not
additional information.
KSP 201

As much as possible ,classes, attributes and associations in the object model should
represent independent information.
Multiple paths between classes often indicate derived associations which are
compositions of primitive associations.
2)Consortium shares ATMs. Is a compositions of primitive associations
20)Consortium owns central computer. and Central computer communicates with
ATMs.
Not all associations that form multiple paths between classes indicate
redundancy. Sometimes the existence of an association can be derived from
two or more primitive associations and the multiplicity can not. Keep the extra
association if the additional multiplicity constraint is important.
6)Misnamed Associations: Don‟t say how or why a situation came about,say what it
is.
4)Bank computer maintains a/cs is a statement of action;rephrase Bank hold a/c.
7)Role Names: Add role names where appropriate.
KSP 202

8) Qualified associations : A qualifier distinguishes objects on the “many” side of an
association.
Ex. The qualifier bank code distinguishes the different banks in a consortium.
8) Multiplicity: Specify multiplicity, but do not put too much effort into getting it right.
9)Missing associations:
Ex.1)Transaction entered on cashier station.
2)Customer have a/cs
3)Transactions authorized by cash card.
4)Cashier authorized on cashier station
KSP 203

Identify Attributes
 Attributes are properties of individual objects,such as name,weight,velocity,or
color. Attributes should not be objects;use an association to show any relationship
between two objects.
 Keeping the Right Attributes:
Eliminate unnecessary and incorrect attributes with the following criteria:
1) Objects: If the independent existence of an entity is important, rather than just its
value, then it is an object. Ex. Boss is an object and salary is an attribute. The
distinction often depends on the application.Ex.in a mailing list city might be
considered as an attribute, while in a census City would be an object. An entity that
has features of its own within the given application is an object.
2)Qualifiers: if the value of an attribute depends on a particular context, then
consider restating the attribute as a qualifier. Ex.Employee number is not a unique
property of a person with two jobs;it qualifies the association Company employs
person.
3)Names: Names are often better modeled as qualifiers rather than object attributes.
Ex.Department name may be unique within a company, but eventually the program
may need to deal with more than one company.
KSP 204

A name is an object attribute when it does not depend on context, especially when it
need not be unique. Names of persons, unlike names of companies, may be
duplicated and are therefore object attributes.
4)Identifiers: OOL incorporate the notion of an object identifier for unambiguously
referencing an object. Do not list these object identifiers in object models, as Object
Identifiers are implicit in object models. Only list attributes which exist in the
application domain.
Ex.account code is a bonafide attribute; Banks assign account codes.
Transaction ID should not be listed as an attribute, although it may be convenient to
generate one during implementation.
5)Link attributes:If a property depends on the presence of a link, then the property is
an attribute of the link and not of a related object. Link attributes are usually obvious
on many-to-many associations; they cannot be attached to either class because of
their multiplicity.Link attributes are more subtle on many-to-one associations because
they could be attached to the “many”object without losing information.They are also
subtle on one-to-one associations.
KSP 205

6)Internal Values: If the attribute describes the internal state of an object that is
invisible outside the object, then eliminate it from the analysis.
7)Fine Detail: Omit minor attributes which are unlikely to affect most operations.
8)Discordant attributes: An attribute that seems completely different from and
unrelated to all other attributes may indicate a class that should be split into two
distinct classes.
Bank code and card code are present on the card. Their format is an
implementation detail, but we must add a new association Bank issues cash
card.
Card code is a qualifier on this association; bank code is the qualifier of Bank with
respect to Consortium
KSP 206

Refining with Inheritance
 Organize classes by using inheritance to share common structure.
 You can discover inheritance from the bottom up by searching for
classes with similar attributes, associations, or operations.
 Remote transaction and Cashier transaction are similar and be
generalized by Transaction.
KSP 207

Testing access paths
1)Trace access paths through the object model to see if they yield sensible results
.Where a unique value is expected, is there a path yielding a unique result?
For multiplicity “many” is there a way to pick out unique values when needed?
2)A cash card itself does not uniquely identify an a/c, so the user must choose an
account somehow. If the user supplies an a/c type(savings, current),each card can
access at most one savings and one current a/c. The alternative is to require
customers to remember a/c nos. If a cash card access a single a/c ,then transfers
between a/cs are impossible.
Assumptions: ATM network serves a single consortium of banks.Real cash m/cs
today often serve overlapping networks of banks and accept credit cards as well as
cash cards.
KSP 208

Iterating OM
1)Signs of missing objects:
a)Asymmetries in associations and generalization: Add new classes by analogy
b)Disparate attributes and operations on a class: Split a class so that each part is
coherent.
c)An operation with no good target class, add the missing target class.
2)Signs of unnecessary classes:
a)Lack of attributes, operations and associations on a class, Why is it needed?
3)Signs of missing associations:
a)Missing access paths for operations: Add new associations so that queries can be
answered.
4)Signs of unnecessary associations include:
a)Redundant information in the associations: remove associations that do not add
new information or mark them as derived.
5)Signs of incorrect placements of associations:
a)Role names that are too broad or too narrow for their classes:move the association
up or down in the class hierarchy
KSP 209

6)Signs of incorrect placement of attributes:
a)Need to access an object by one of its attribute values: Consider a qualified
association.
In practice ,model building is not as rigidly ordered as we have discussed. we can
combine several steps once we are experienced.
Ex. Cash card really has split personality: It is both an authorization unit within the
bank allowing access to the customer’s a/cs and also a piece of plastic data that the
ATM reads to obtain codes IDs.
The codes are actually part of the real world, not just computer artifacts; the codes,
not the cash card, are communicated to the central computer.
Split cash card into two objects: Card authorization(an access right to one or more
customer a/cs; and Cash card(a piece of plastic data that contains a bank code and a
cash card number meaningful to the bank)
Transaction consists of one or more updates on individual a/cs. An update is a
single action(withdrawl, deposit,or query)on a single a/c. All updates in a single
transaction must be processed together as an atomic unit;if any one fails,then they all
are canceled.
KSP 210

The distinction between Bank and Bank computer and Consortium and Central
computer dose not seem to affect the analysis.So merge them.
Bank computer into Bank and Central computer into Consortium.
KSP 211

Grouping classes into Modules
ATM example is small and would not require breakdown into modules,but we can
have some modules:
Tellers: Cashier ,Entry Station, Cashier Station, ATM
Accounts:Account,CashCard,Card
authorization,Customer,Transaction,Update,Cashier,Transaction,Remote
Transaction.
Banks:Consortium,Bankl
KSP 212

Dynamic Modeling
1)DM shows the time dependent behaviour of the system and the objects in it.
2)Begin dynamic analysis by looking for events – externally-visible stimuli and
responses.
3)Summarize permissible event sequences for each object with a state diagram.
4)DM is insignificant for purely static data repository(database).
5)DM is important for interactive systems.
KSP 213

Steps in constructing a DM
1)Prepare scenarios of typical interaction sequences.
2)Identify events between objects
3)Prepare an event trace for each scenario
4)Build a state diagram
5)Match events between objects to verify consistency.
KSP 214

Preparing a scenario
1)First prepare scenarios for normal cases, interactions without any unusual inputs or
error conditions.
2)Then consider special cases, such as omitted input sequences, max and min
values,and repeated values.
3)Then consider error cases, including invalid values and failures to respond
4)For many interactive applications, error handling is the most difficult part of the
implementation. If possible allow the user to abort an operation or roll back to a well
defined starting point at each step.
5)Also consider interactions :help request and status queries.
KSP 215

Interface formats
Most interactions can be separated in two parts:
Application logic and UI(user interface)
The analysis should concentrate first on the information flow and control, rather than
the presentation format.
The same program logic can accept input from command lines,files,mouse
buttons,touch panels,physical push buttons,or remote links,if the surface details are
carefully isolated .
The DM captures the control logic of the application.
It is hard to evaluate UI without testing it.Often the interface can be mocked up so that
users can try it.
Application logic can often be simulated with dummy procedures.
Decoupling application logic from UI allows the “look and feel” of the UI to be
evaluated while the application is under development.
KSP 216

Identifying Events
Examine the scenarios to identify all external events. Events include all signals,
inputs, decisions, interrupts, transitions, and action to and from users and external
devices.
Internal computation steps are not events, except for decision points that interact with
the external world.
Use scenarios to find normal events, but don‟t forget error conditions and unusual
events.
Group together under a single name events that have the same effect on flow of
control,even if their parameter values differ. Ex enter password should be an event
class,since the password value does not affect the flow of control.
Dispense cash is also an event class,since the amount of cash dispensed does not
affect the flow of control.
Events that affect the flow of control should be distinguished.
A/c ok,bad a/c,bad password are all different events;don‟t group them under card
status.
KSP 217

You must decide when differences in quantitative values are important enough to
distinguish. Ex, Different digits from keyboard would usually be considered the same
event, since the high level control does not depend on numerical values.
Pushing the enter key however, would probably be considered a distinct event, since
the application would respond differently.
The distinction depends on application. You may have to construct the state diagram
before you can classify all events; some distinctions between events may have no
effect on behaviour and can be ignored.
Allocate each type of event to the object classes that send and receive it.
KSP 218

System Design
1)Organize the system into subsystems
2)Identify concurrency inherent in the problem
3)Allocate subsystems to processors and tasks
4)Choose an approach for management of data stores
5)Handle access to global resources
6)Choose the implementation of control in s/w
7)Handle boundary conditions.
8)Set trade-off priorities
KSP 221

 S/w architecture: A s/w architecture of a program or computing system is
the structure or structures of the system, which comprises s/w
components, the externally visible properties of those components and
the relationship among them.
 The architecture is not an operational s/w, it is the representation that
enables a s/w engineer to :
 a) Analyse the effectiveness of the design in meeting its stated
requirements.
 b)Consider architectural alternatives at a stage when making design
changes is still relatively easy.
 c)Reduce the risks associated with the construction of the s/w.
KSP 222

 Architecture: The design and construction of buildings.(Overall structure
of the s/w and the ways in which that structure provides conceptual
integrity for a system )(It is structure or organization of program
components(modules),the manner in which these components interact
and the structure of the data used by the components.)
 Design: A plan or drawing produced to show the appearance and
workings of something before it is made.
 s/w architecture: two levels of design a)Data Design b)Architectural
Design
 Data Design: Represent the data component of the architecture in
conventional systems and class definition(attributes + operations) in OO
systems.
 It creates a model of data and/or information that is represented at a high
level of abstraction (the customer/user‟s view of data).
KSP 223

 This data model is than refined into progressively more implementation
specific representations that can be processed by the computer based
system.
 The structure of data is important part of s/w design .At Program
component level ,design of DS and algorithms required to manipulate
them is essential to create high quality application
 At application level translation of a data model into d/b is important for
business objectives of the system.
Architectural Design: Focus on the representation of the structure of s/w
components ,their properties and interactions.
AD for s/w is the equivalent to the floor plan of a house .The floor plan
depicts the overall layout of rooms, their size, shape, relationship to one
another. And the doors and windows that allow movement into and out of
the rooms the .The floor plan gives us the overall view of the house .
KSP 224

 AD gives overall view of s/w. Architectural Model derived from three
sources:
 A)Information about the application domain for the s/w to be built.
 B)Specific analysis model elements such as DFD or analysis classes
their relationships and collaboration.
 C)Availability of architectural patterns and styles.
KSP 225

Decomposition of system into subsystems
 Horizontal layers or vertical partitions
 Each built in terms of the ones below it and providing the basis of
implementation for ones above it
 The objects in each layer can be independent
 Although there is some correspondence between object in different
layers
 Knowledge is one-way only
 A subsystem knows about the layer below it but no knowledge of layers
above it.
 Lower layer-Providers of services
 Upper layer-Users of Services
KSP 226

Layered Architecture
Closed architecture: Each layer is built in terms of immediate lower layer
-reduces dependencies between layers
-Allows changes to be made easily as layer‟s interface only affects the next
layer
Open Architecture: A layer can use features of any lower layer to any
depth
-Reduces the need to redefine operations at each level
-results in more efficient and compact code.
-No information hiding
-less robust as changes to subsystem can affect any higher subsystems.
Usually only top layers and bottom layers are specified by problem
statement
i)Top layers-desired system
ii)Bottom layer-Resources(H/w,OS,lib)
KSP 227

 If disparity between i) and ii) is too great as often ,introduce intermediate
layers to reduce the gap.
Subsystem: is identified by the services it provides
Services :a group of related functions that share some common purpose
such as I/o processing ,drawing pictures,performing arthematic etc
The file system within an OS is a subsystem, memorymgmt etc.
-Each subsystem has well defined interface to the rest of the system.
-The interface specifies the form of all interactions and information flow
across the subsystem boundaries but does not specify how the subsystem
is implemented internally.
-Subsystems are defined so that most interactions are within the
subsystems rather than across the subsystems boundaries in order to
reduce the dependencies among the subsystem.
KSP 228

-Each subsystem may be decomposed into smaller subsystems of its own.
The lowest level subsystems are called modules.
-The relation between two subsystems :client-server or peer to peer.
-Client calls on supplier which performs some services.
-Client must know the interfaces of supplier but supplier does not have to
know the interfaces of clients, because interactions are initiated by clients
using supplier interfaces.
-peer to peer relationship- each of the subsystem may call on the others.A
communication from one subsystem to another is not necessarily followed
by an immediate response.
-interactions are more complicated because the subsystems must know
each other’s interfaces, communication cycles can exist that are hard to
understand and liable to design errors.
KSP 229

-look for supplier client decomposition whenever possible because one-way
interaction is much easier to built ,understand and change than a two-way
interaction.
Partitions-vertically divide a system into independent or weakly-coupled
subsystems each providing one kind of service.
Ex OS includes :File system, process control, virtual memory mgmt, device
control etc.
KSP 230

Identify concurrency
1)In the analysis model ,as in the real world and in H/w,all objects are concurrent.
2)In implementation,however,not all s/w object are concurrent because one processor
may support many objects.In practice,many objects can be implemented on a single
processor if the objects cannot be active together.
3)One important goal of System Design is to identify which objects must be active
concurrently and which objects have activity that is mutually exclusive.
4)For identifying inherent concurrency dynamic model is the guide .
5)Two objects are inherently concurrent if they can receive events at the same time
without interacting. If the events are unsynchronized, the objects cannot be folded
onto a single thread of control.
Ex.engine and the wing controls on an airplane must operate concurrently.
6)bIndependent subsystems are desirable because they can be assigned to different
h/w units without any communication cost.
KSP 231

7)Two subsystems that are inherently concurrent need not necessarily be
implemented as separate h/w units.
8)The purpose of h/w interrupts ,OSs, and tasking mechanism is to simulate logical
concurrency in a uniprocessor
9)Defining concurrent tasks: Although all objects are conceptually concurrent, In
practice many objects in a system are interdependent. By examining the state
diagrams of individual objects and the exchange of events among them, many objects
can often folded onto a single thread of control.
A thread of control is a path through a set of state diagrams on which only a single
object at a time is active.
A thread remains within a state diagram until an object sends an event to
another object and waits for another event. The thread passes to the receiver
of the event until it eventually returns to the original object.The thread splits if
the object sends an event and continues executing.
KSP 232

10)On each thread of control ,only a single object at a time is active. Thread of control
are implemented as tasks in computer systems.
Ex. While the bank is verifying an a/c or processing a bank transaction, the ATM m/c
is idle. If the ATM is controlled directly by a central computer ,then the ATM object
can be folded together with the bank transaction object as a single task.
KSP 233

Allocating Subsystems to Processors and Tasks
1)Each concurrent subsystem must be allocated to a h/w unit, either a general
purpose processor or a specialized functional unit. The system designer must:
a)Estimating H/w resources requirements.
b) H/W –S/W Trade Offs.
c) Allocating Tasks to Processors.
d) Determining Physical Connectivity
KSP 234

a)Estimating H/w resources requirements.
1)The decision to use multiple processors or H/w functional units is based on a need
for higher performance than single CPU can provide.
2)The number of processors required depends on the volume of computations and
the speed of the machine.
Ex.,a military radar system generates too much data in too short a time to handle in a
single CPU, even a very large one.
The system designer must estimate the required CPU processing power by
computing the steady state load as the product of the number of transactions per
second and the time required to process a transaction.
The estimate will usually be imprecise.
KSP 235

b) H/w-S/w Trade-Offs
1)H/w can be regarded as a rigid but highly optimized form of s/w. The OO view is a
good way of thinking about h/w. Each device is an object that operates concurrently
with other objects(other devices or s/w)
2)The system designer must decide which subsystems will be implemented in h/w
and which in s/w. Subsystems are implemented in h/w for two main reasons:
a)Existing h/w provides exactly the functionality required. Today it is easier to buy a
floating point chip than to implement floating point in s/w.Sensors and actuators must
be h/w.
b)Higher performance is required than a general purpose CPU can provide, and more
efficient h/w is available .Ex ,chips that perform the FFT are widely used in DSP
applications.
KSP 236

Handling Global Resources
1)The system designer must identify global resources and determine mechanisms for
controling access to them.Global resources include:
Physical units: processors, tape drives, and comm satellites.
Space:disk space,workstation screen,buttons on mouse,
Logical names: Object IDs,filenames,classnames
And access to shared data,such as databases.
2)If the resource is a physical object ,then it can control itself by establishing a
protocol for obtaining access within concurrent system.
3)If the resource is a logical entity, such as an object ID or a database, then there is
danger of conflicting access in a shared environment.Independent tasks could
simultaneously use the same objectID,Ex.
KSP 237

Each GR must be owned by a “guardian object” that controls access to it.
One GO can control several resources .All access to the resource must pass through
the GO.Ex,most d/b managers are free-standing tasks that other tasks can call to
obtain data from the database.
Allocating each shared GR to a single object is a recognition that the resource has
identity.
Logical resource can also be partitioned logically ,such that subsets are assigned to
different GO for independent control.
Ex.one strategy for object ID generation in a parallel distributed environment is to
preallocate a range of possible IDs to each processor in a network;
Each processor allocates the IDs within its preallocated range with out the need for
global synchronization.
KSP 238

 In a time-critical application, the cost of passing all access to a resource through a
GO is sometimes too high, and clients must access the resource directly.
 In this case ,LOCKS can be placed on subsets of the resource.
 A LOCK is logical object associated with some defined subset of resource that
gives the LOCK holder the right to access the resource directly.
 GO must still exist to allocate the LOCKS,but after one interaction with the
guardian to obtain a LOCK the user of the resource can access the resource
directly.
 This approach is more dangerous because each resource user must be trusted to
behave itself in its access to the resource.
 The use of direct access to shared resources should be discouraged in an OO
design unless absolutely necessary.
KSP 239

S/w control implementation
 During analysis, all interactions are shown as events between
objects.
 H/w closely matches the analysis model, but the system designer
must choose among several ways to implement control in s/w.
 There is no logical necessity that all subsystems use the same
implementation, usually designer chooses a single control style
for the whole system.
 There are two kinds of control flows in a s/w system:
i)Internal control.
ii)External control.
KSP 240

Internal Control External Control
Flow of control within a process. It
exists only in the implementation &
therefore is not inherently concurrent
or sequential.
The designer may choose to
decompose a process into several
tasks for logical clarity or for
performance(if multiple processors
are available)
Three kinds of control flows:
i)Procedure calls.
ii)Quasi-concurrent inter-task call.
iii)Concurrent inter-task call.
Is the flow of externally-visible events
among the objects in the system.
Three kinds of control for external
events:
i)Procedure-driven
sequential(systems).
ii)Event-driven sequential(systems).
iii)Concurrent
KSP 241

Procedure-driven Systems Event-driven Systems
Control resides within the program code.
Procedures issue request for external
input and then wait for it; when input
arrives, control resumes within the
procedure that made the call.
Control resides within a dispatcher or
monitor provided by the language,
subsystem,or OS. Application procedures
are attached to events & are called by the
dispatcher when the corresponding
events occur(“callback”)
The location of the PC & the stack of
procedure calls & local variables define
the system state.
Procedure calls to the dispatcher send
output or enable input but do not wait for
it in-line.
All procedures return control to the
dispatcher, rather than retaining control
until input arrives. Events are handled
directly by the dispatcher.
Program state can not be preserved
using PC & stack because procedures
return control to dispatcher
KSP 242

Procedure-driven Systems Event-driven Systems
Adv:It is easy to implement with conventional
languages;
Disadv:it requires the concurrency inherent in
objects to be mapped into sequential flow of
control.
The designer must convert events into
operations between objects. A typical operation
corresponds to a pair of events: an output event
that performs output & requests input & an input
event that delivers the new values.
Procedures must use global variables to
maintain state or the dispatcher must maintain
local state for them. Event driven control is
more difficult to implement with standard
languages than procedure-driven control.
Event driven systems permit more flexible
patterns of control than procedure-driven
systems. They simulate cooperating processes
within a single multi threaded task;an errant
procedure can block the entire application,so
care must be taken.Event driven user interface
subsystems are particularly useful.
Ex:SunView,X-Windows
A synchronous input cannot be easily
accommodated with this paradigm. Because the
program must explicitly request input.
It suitable only if the state model shows a
regular alternation of input & output
events.Flexible UI‟s&Control Systems are hard
to build using this style.
KSP 243

 Use an Event-driven system for external
control in preference to a procedure
driven system whenever possible
because the mapping from events to
program constructs is much simpler and
powerful.
 Event driven systems are more modular
& can handle error conditions better than
procedure driven systems.
KSP 244

Handling Boundary Conditions
Initialization Termination Failure
The system must be brought from a
quiescent initial state to a
sustainable steady state condition.
Things to be initialized include
constant data,parameters,global
variables,tasks,GOs,
class hierarchy.
Is usually simpler than initialization-
many internal objects can simply be
abandoned.
Failure is the unplanned termination
of a system.Can arise from user
error, from the exhaustion of system
resources,or from an external
breakdown
During initialization only a subset of
the functionality of the system is
usually available.
The task must release any external
resources that it had reserved.
The good system designer plans for
orderly failure.Failure can also arise
from bugs in system & is often
detected as an “impossible”
inconsistency.
Initializing a system containing
concurrent tasks is most difficult –
independent objects must not get
either too far ahead or too far
behind other independent objects
during initialization
In a concurrent system,one task
must notify other tasks of its
termination.
In a perfect design,such errors
would never happen,but the good
designer plans for a graceful exit on
fatal bugs by leaving the remaining
environment as clean as possible &
recording or printing as much
information about the failure as
possible before terminating
KSP 245

Concurrent systems
 Concurrent computing is a form of computing in which several
computations are executing during overlapping time periods –
concurrently – instead of sequentially (one completing before the next
starts).
 A concurrent system is one where a computation can make progress
without waiting for all other computations to complete – where more than
one computation can make progress at "the same time“.
 Concurrent computing is related to but distinct from parallel computing,
though these concepts are frequently confused, and both can be
described as "multiple processes executing during the same period of
time".
 In parallel computing, execution literally occurs at the same instant, for example on separate
processors of a multi-processor machine, with the goal of speeding up computations – parallel
computing is impossible on a (single-core) single processor, as only one computation can
occur at any instant (during any single clock cycle)
KSP 246

 concurrent computing consists of process lifetimes overlapping, but
execution need not happen at the same instant. The goal here is to
model processes in the outside world that happen concurrently, such as
multiple clients accessing a server at the same time.
 Pioneers in the field of concurrent computing include Edsger Dijkstra,
Per Brinch Hansen, and C.A.R. Hoare.
 For example, concurrent processes can be executed on a single core by
interleaving the execution steps of each process via time slices: only one
process runs at a time, and if it does not complete during its time slice, it
is paused, another process begins or resumes, and then later the original
process is resumed. In this way multiple processes are part-way through
execution at a single instant, but only one process is being executed at
that instant.
KSP 247

 The exact timing of when tasks in a concurrent system are executed
depend on the scheduling, and tasks need not always be executed
concurrently. For example, given two tasks, T1 and T2:
 T1 may be executed and finished before T2
 T2 may be executed and finished before T1
 T1 and T2 may be executed alternatively (time-slicing)
 T1 and T2 may be executed simultaneously at the same instant of time
(parallelism)
 The main challenge in designing concurrent programs is concurrency
control: ensuring the correct sequencing of the interactions or
communications between different computational executions, and
coordinating access to resources that are shared among executions.
 Potential problems include race conditions, deadlocks, and resource
starvation
KSP 248

Setting Trade-Off Priorities
 The designer is often required to choose among desirable but
incompatible goals.
 Ex.A system can often be made faster by using extra memory.
 Design trade-offs must be made regarding not only the s/w itself but also
regarding the process of developing it.
 Sometimes it is often necessary to sacrifice complete functionality to get
a piece of s/w into use(or into market place)earlier.
 All the trade-offs are not made during design,but the priorities for making
them are established.
 Ex.Video games ran on processors with limited memory. Conserving
memory was the highest priority, followed by fast execution.
 Designers must use every programming trick at the expense of
maintainability, portability,& understandability.
KSP 249

 There are several mathematical subroutine packages available on a wide
range of machines. This can not be sacrificed for fast development.
 A UI is hard to evaluate without actually using it. The designer often uses
rapid prototyping, which is a “quick & dirty” implementation of a part of
the system to be evaluated, while ignoring or simulating the rest of the
system.
 Rapid prototyping minimizes initial design time by sacrificing
completeness of functionality, efficiency,and robustness.
 Once the prototype is evaluated,the interface can be reimplemented
using design trade-offs,& the remainder of the system can be
implemented.
 The entire character of the system is affected by the trade-off decisions
made by the designer.
 The success or failure of the final product may depend on whether its
goals are well chosen.
KSP 250

 If no system-wide priorities are established, then various parts of the
system may optimize opposing goals(“suboptimization”),resulting in a
system that waste resources. Even on small projects, programmers often
forget the real goals & become obsessed with “efficiency” when it really
is not important.
 Setting trade off priorities is at best vague. You can not expect numerical
accuracy (“speed 53%,memory 31%,portability 15%,cost 1%).Priorities
are rarely absolute ;
 for ex. trading memory for speed does not mean that any increase in
speed, no matter how small, is worth any increase in memory, no matter
how large.
 Priorities are a statement of design philosophy by the designer to guide
the design process. Judgement and interpretation are required when
trade-offs are actually made during the rest of the design.
KSP 251

Oomd2015

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Oomd2015

Similar to Oomd2015 (20)

Recently uploaded

Recently uploaded (20)

Oomd2015