Download - 4.1 Object-oriented development approaches IMS5006 - Information Systems Development Practices
4.1
Object-oriented development approaches
IMS5006 - Information Systems Development Practices
4.2
System development approaches
three basic approaches to systems development:
functionalprocess decomposition is the basis
data used by processes
data-centreddata is the stable basis
process decomposition to define functions
object-orienteddata, process and behaviour combined in one object
“objects” structure the application domain
4.3
Data
Process
Behaviour
These three perspectives are encapsulated within the object.
The three perspectives of an information system
4.4
Object-oriented development is built around the concept of modelling a system in terms of objects
An object encapsulates data, process and behaviour
Programming languages first, then analysis and design
Object-oriented development
4.5
Object-oriented and conventional approaches
Conventional
Object-oriented
Process Database
Data
Process
Data
Process
message
message
The emphasis is on object structure NOT on procedure structure
4.6
Object-oriented approaches
claimed benefits:
“seamless” development process shift of development effort into analysis:
conceptual models, not computer models facilitates reuse increased consistency between analysis, design
and programming activities and models more “natural” modelling of the problem domain a “cleaner” design
4.7
Object-oriented development
An object is a thing (tangible or a concept) that has a well-defined role in the application domain
It has an identity, state and behaviour, and is something to which actions are directed
Its state encompasses its properties (attributes and relationships) and their values
Its behaviour is how it acts and reacts
4.8
Object-oriented development lifecycle
The OO lifecycle consists of progressively developing an object representation through 3 phases:analysis, design and implementation
In the early stages, the model is abstract, focusing on the external qualities of the application As the model evolves, it becomes more detailed, focusing on how the system will be built and how it will
function Focus on front-end conceptual issues, not back-end implementation issues to avoid restricting design
choices
4.9
Analysis: a model of the real-world application abstracting concepts describing what the system must do
Design: System design: overall system architecture, subsystems
(the context for physical design decisions) Object design: add design detail e.g. internal data
structures and algorithms, efficiency tuning, control, associations, module packaging
Implementation: implement design using programming languages, DBMS etc.
Example object-oriented development lifecycle
4.10
Object-oriented notations
Various object-oriented approaches have been proposed with various modelling notations in late 80s and early 90s e.g. Booch’s Booch Method, Rumbaugh et al’s Object Modelling Notation (OMT), Jacobson et al’s Object-oriented Software Engineering (OOSE), Coad and Yourdon’s Object-oriented Analysis (OOA)
Booch, Rumbaugh, Jacobson created a standard modelling language: Unified Modelling Language (UML) with version 1.0 released in 1997
UML is widely-accepted standard for notation
4.11
Object-oriented modelling
Object class diagrams show the static structure of the application domain
Dynamic models represent the dynamic behaviour of the system
Operations represent the processes of the system and are triggered by events
4.12
Object class: group of objects with similar properties, behaviour,
relationships and semantics each object is in one class
(an inherent property of the object) objects have identity: objects are distinct even if all
their attribute values and operations are the same an object has a state and exhibits behaviour through
operations that can examine or inspect its state attribute: a data value held by objects in a class
Object modelling
4.13
Object modelling: class diagrams
Employee
Employee idEmployee nameEmployee addressEmployee D-O-B
Create new employeeChange employee
address
Class name
Operations
Attributes
Object class diagram
Ian Smith: Employee
Employee id = 345Employee name=Ian SmithEmployee address =Caulfield, VicEmployee D-O-B =4/10/64
Object instance diagram
4.14
abstraction encapsulation information hiding polymorphism inheritance messaging
Object Modelling Concepts
4.15
Abstraction in object modelling
hide detail to focus our attention on selected aspects of the system
Identification
Classification Association Generalisation Aggregation
4.16
Classification groups objects into classes group objects based on similarity inherently subjective based on common attributes, behaviour or semantics
for example: Polygon Objects
Polygon Class
Attributes: vertices border-colour fill-colour
Operations: draw erase move
4.17
Association
means of establishing relationships between objects and object classes
group of conceptual links between objects exists independently of objects an association is a group of links with
common structure and semantics describes a set of potential links inherently bi-directional degree may be unary, binary, ternary etc.
4.18
Associations
often implemented as pointers
an association is independent of object classes
Country City
(Country) (City)
(Country) (City)
Australia Canberra
Indonesia Jakarta
name nameClass Diagram
Instance Diagram
Has-capital
Has-capital
Has-capital
4.19
Association
employeeis-assigned
customerplaces
studentenrols-in
multiplicity indicates how many instances participate in the association
parkingpermit
sales order
subject
0..1 0..1
1 1..*
* *
one-to-one
one-to-many
many-to-many
4.20
Association
ternary or higher order associations may be represented
Project Language
Person
(Person)Mary
(Project)Accounting System
(Project)CADprogram
(Language)Cobol
(Language) C++
*
*
*
4.21
Generalisation
group object classes based on similarity powerful abstraction technique for sharing similarities
between classes the class being refined is the “superclass” and each
refined version is a “subclass” each object can have many subclasses and many
superclasses sometimes called the “is-a” or “ako” relationship the generalisation relationship may be specified by a
discriminating attribute: the discriminator
- the basis for the generalisation
4.22
GeneralisationConnector
LocationDiameterLength
displayLocationdisplayDiameterdisplayLengthupstreamPipe
Free Flow Connector Network Connector
openWaterSupply: {abstract}closeWaterSupply: {abstract}
Pump Connector
onoff
Service Outlet Valve ConnectorPermit NumberopenWaterSupplycloseWaterSupply
openWaterSupplycloseWaterSupply
connector type
network connector type
4.23
Inheritance
each subclass is said to inherit the features of its superclass
generalisation and inheritance are transitive across levels (ancestor and descendant)
each subclass not only inherits all features of its ancestors but adds further specific attributes and operations
inheritance is a major benefit of OO derived by implementing generalisation structures
4.24
Use of generalisation
both conceptual modelling and implementation
structuring classes based on similarity and difference
mechanism for inheritance
reuse of library classes
4.25
Disjoint and overlapping subclasses
Disjoint subclasses each instance belongs to exactly one of the subclasses E.g. Hourly-employee, Salaried-employee, Exempt-employee indicated using braces in UML notation Overlapping subclasses each instance can belong to more than one subclass e.g. graduate student, part-time student indicated using braces in UML notation Complete and incomplete subclasses in UML notation this indicates whether additional
subclasses are expected
4.26
all students are either graduate or undergraduate
graduate students may hold one or both types of assistantships
Disjoint and overlapping subclasses
student
graduatestudent
undergraduate student
researchassistant
teachingassistant
student level
assistantship type
{complete, overlapping}
{complete, disjoint}
4.27
where a class has more than one superclass and inherits from all parents
brings greater power to modelling but with loss of conceptual simplicity
Multiple Inheritance
vehicle
landvehicle
watervehicle
amphibious vehicle boatCar
4.28
Aggregation
a grouping of component classes: a “part-of” relationship representing components and
assemblies a special form of association where component classes do
not have independent existence
transitivity:
If A is-part-of B and B is-part-of C
then A is-part-of C anti-symmetric:
If A is-part-of B then B is NOT part-of A
4.29
aggregation
relates an assembly class to ONE component class and allows us to specify multiplicity of each component
Document Paragraph Sentence* *
4.30
Aggregation
Car
DriveSystem
ElectricalSystem
FuelSystem
• • •
Alternator Battery Coil
• • •
1-2
aggregation and generalisation are commonly confusedbecause of the hierarchical nature of both constructs
4.31
Aggregation and Generalisation
aggregation groups unlike instances (AND) generalisation groups similar classes (OR)
Network
ConnectorPipe
Free FlowConnector
NetworkConnector
note: associations betweenPipe and Connector have been omitted
PumpConnector
4.32
Aggregation or Association?
For aggregation:
- would you use the phrase “part of”?
- are some operations on the assembly automatically applied to its parts? E.g. copy document so copy paragraphs
- are some attribute values propagated from the assembly to its parts? E.g. car speed is 60 kph so car door speed is 60 kph
- is there an intrinsic “asymmetry” to the association?
4.33
Encapsulation and Information Hiding
encapsulation and information hiding are often used interchangeably
they are related concepts but not the same
encapsulation is the containment of data and behaviour within an object
information hiding refers to the restricted interface an object offers to its internal workings:
the object “hides” its internal implementation details -
messages are required to access the object’s data or status
4.34
the state of an object includes its properties (attributes and associations) and the values they have: it is determined by its attribute values and links
the behaviour of an object is how it acts and reacts:it is determined by its state and the operation being performed
an operation is a function or transformation that may be applied to or by an object in a class
eg. COMPANY hire, fire, pay-dividend
a method is an implementation of an operation in class
Object states and behaviour
4.35
Polymorphism
polymorphism = “many forms” same operation may behave differently on different classes
An operation may have more than one method implementing it.
The correct method is selected based on the class and operation names.
an operator may have arguments (parameters) methods for same operator must have same signature
(number and type of arguments and type of result value) behaviour of all methods for an operation should have
consistent intent
E.g.print
Picture file
Binary file
4.36
operations are listed in third part of class box can include parameter list and result type $ indicates an operation performed on the whole object
Operation notation
Person
Name: stringAddress: stringAge: integer
change-namechange-address$createPerson
Geometric Object
color: stringposition: point
move (delta:Vector)select (p:point): Booleanrotate (angle)
4.37
Dynamic modelling Characterises temporal nature of system :
describes changes to object classes and relationships over time
Deals with flow of control, interactions and sequences of operations in a system of concurrently active objects (message passing)
Shows object states and events, and operations as actions and activities
Use state diagrams and sequence diagrams
4.38
Scenarios and sequence diagrams
a scenario is a sequence of events that occurs during one particular execution of a system
E.g.
consumer inserts coin ($1)interface displays amount ($1)letter selection button pressed (A)interface displays letter (A)number selection button pressed (1)interface displays number (1)food dispenser dispenses item (A1)
4.39
Sequence diagrams
show the sequence of events and the objects exchanging events
consumer inserts coin ($1)
interface displays amount ($1)
letter selection button pressed (A)
interface displays letter (A)
number selection button pressed (1)
interface displays number (1)
food dispenser dispenses item (A1)
consumer interface food dispenser
4.40
Example state diagram
Idle
Dispensing
Waiting forletter
Waiting fordigit
money Inserted
[letter valid]
[digit valid]
[digit invalid]
[letter invalid]
an event is received from the coin collector (moneyInserted)
the conditions indicate processing within the food dispenser object and not the state of the coin collector.
ButtonPressed (name)
ButtonPressed(name)
4.41
Message passing is the means of communication between objects in an application
A message is passed when an object invokes one or more of another object’s operations to request information or some action
Can create an Object Communication Model Form: operation name (arguments)
Messaging
Food selection panel
Dispenser Coin Slot
dispense(selection) amount paid?
100
E.g. Food Vending Machine
4.42
UML (Uniform Modelling Language)
Major analysis models in UML:
use cases:represent the functional requirements (the “what”) of the system
class diagrams:the static structure of data and operations that act on the data
state diagrams:represent how objects change their states in response to events
sequence diagrams:represent dynamics of of the interactions between objects
4.43
use case: a complete sequence of related actions initiated by an actor
(scenarios) use cases may be extended by or used by another use case
class diagram: models the object classes and their attributes and operations
state diagram: models the states of an object and the events that cause state
transitions
sequence diagrams: shows the passing of messages between objects
UML (Uniform Modelling Language)
4.44
Coad & Yourdon’s OOA five major activities:
1. find class-&-objects
2. identify structures
3. identify subjects
4. define attributes
5. define services
activities may be iterative, and there is no strict sequence
4.45
find class-&-objects: identify object classes that form the core of the applicationidentify structures: organise the classes into generalisation (gen-spec) and aggregation
(whole-part) hierarchiesidentify subjects: group the object model into manageable subject areas to create
subject layer and structure layerdefine attributes: identify data elements of each classdefine services of each class: a service is the operation or processes performed by the object in
response to receipt of a message; service charts specify details
Coad & Yourdon’s OOA
4.46
Advantages of object-oriented approaches reduced semantic gap between models and problem domain
greater semantic richness particularly in the use of inheritance to explicitly represent commonality
re-usability is encouraged: not code libraries but object libraries
“seamless” development and increased consistencyof activities and models: traceability of objects
effect of changes to an object is more localised
message passing convention leads to easier interface descriptions between objects
4.47
References
AVISON, D.E. & FITZGERALD, G. (2003). Information Systems Development: Methodologies, Techniques and Tools. (3rd ed), McGraw-Hill, London.
Chapter 21
HOFFER, J.A., GEORGE, J.F. and VALACICH (1999) 2nd ed., Modern Systems Analysis and Design, Benjamin/Cummings, Massachusetts.
Chapter 12
WHITTEN, J.L., BENTLEY, L.D. and DITTMAN, K.C. (2001) 5th ed.,
Systems Analysis and Design Methods, Irwin/McGraw-HilI, New York, NY.
Modules A, B