ObjectOriented Software Engineering

1
Object-Oriented Software Engineering

• Dr Zhonglin He
• University of Ulster

2
Object-Oriented Software Engineering

• Objectives
• Concepts
• encapsulation, object, attribute, class,
  instance, state, behaviour, operation, message,
  inheritance, polymorphism
• differences between conventional and OO
  approaches
• OO analysis OO design
• Steps in OO Design Advantages of OO approach
• OO testing
• OO modelling
• object models, inheritance models, multiple
  inheritance, object aggregation
• UML notations
• class, object, association, multiplicity,
  aggregation, inheritance, class diagram, use case
  diagram, sequence diagram, collaboration diagram,
  state diagram

3
Object-Oriented Software Engineering

• We live in a world of objects. These objects
  exist in nature, in manmade entities, in
  business, and in the products that we use. They
  can be categorized, described, organized,
  combined, manipulated, and created. Therefore, it
  is no surprise that an object-oriented view would
  be proposed for the creation of computer software
  - an abstraction that enables us to model the
  world in ways that help us to better understand
  and navigate it. - Pressman,Roger, Software
  Engineering, McGraw-Hill, 2000
• proposed in the late 1960s
• OO programming languages SIMULA -67, Smalltalk -
  80, Ada, Eiffel, C, Java
• are replacing classical software development
  approaches, why?
• software professionals simply yearned for a new
  approach
• leads to reuse -gt faster development -gt higher
  quality programs
• easier to maintain because it structure is
  inherently decoupled
• fewer side effects when changes have to be made

4
Object-Oriented Software Engineering

• Ref Bell et al, ch. 9
• Object-Oriented Concepts
• Traditional design methods are based on
  identifying functions
• Object oriented design is about identifying
  objects
• Objects - furniture, chair, desk, pen, page ....
• Objects have characteristics - properties or
  attributes
• desk has cost, dimension, weight, location,
  colour etc
• In programming the same set of attributes are
  said to belong to a class
• An individual object e.g the desk you are sitting
  at are instances of that class (desk)

5
Object-Oriented Software Engineering

• Object-Oriented Concepts
• instances have the same attributes but different
  values to distinguish them
• e,g, In the class Desk, MyDesk is black, YourDesk
  is brown
• The set of attributes then constitute the state
  of an object
• In the object oriented approach an object has two
  parts
• state
• object
• behaviour
• behaviour way in which the object acts on other
  objects or is acted on by other objects
• e.g. Class Desks methods buy, sell, move

6
Object-Oriented Software Engineering

• Object-Oriented Concepts
• An objects behaviour is described in terms of
  the operations provided by that object
• e.g. behaviour will most likely describe state
  changes of an object (Remember - the state is
  described by the attributes)
• operations are invoked by sending messages

7
Object-Oriented Software Engineering

• Object-Oriented Concepts
• Example
• object - Library customer
• attributes - Name, Address, BooksOnLoan
• services e.g.
• to create an instance of customer
• to delete an instance of customer
• to query the number of books on loan
• etc etc
• Definition An object is an encapsulation and an
  abstraction an encapsulation of attributes and
  exclusive services on those attributes an
  abstraction of the problem space, representing
  one or more occurrences of something in the
  problem space.

8
Object-Oriented Software Engineering

• Object-Oriented Concepts
• Inheritance a key differentiator between
  conventional and OO systems. A subclass inherits
  all of the attributes and operations associated
  with its superclass. Any changes to the
  superclass is immediately inherited by all the
  subclasses.

Book
Fictional Book
Non-Fictional Book
Adventure
Thriller
Biography
Scientific
Philosophy
Book is a generalisation (or superclass) of
Fictional and Non-Fictional Fictional is a
specialisation (or subtype, subclass) of Book
9
Object-Oriented Software Engineering

• Object-Oriented Concepts
• All books have an ISBN, Author etc (attributes in
  the superclass)
• Objects lower in the hierarchy inherit attributes
  from those above
• For example, the attribute NumberOfPages can be
  defined at the level of Book rather than
  Biography. Biography inherits the attribute
  from Book
• Messages are sent from one object to another and
  may invoke a service.
• e.g. DetermineNoOfBooksOnLoan may invoke the
  service NumberOfBooksOnLoan in an instance of
  the Member object.
• Polymorphism
• The same message can be sent to different objects
  and invoke different services. E.g.
  DetermineNoOfBooksOnLoan could be sent to
  Member or LibrarySection and cause different
  operations.

10
Object-Oriented Software Engineering

• How do conventional and object-oriented
  approaches differ?
• Traditional approach(process-oriented) is based
  on identifying functions while the OO approach is
  based on identifying objects
• OO is closer to the real world (focuses on
  problem not solution)
• OO enables the smooth transition from
  requirements analysis to design
• OO is flexible of adapting changes
• Objects are more stable than functions, and
  easier to be reused
• Encapsulation packages data and the operations
  that manipulate the data into a single named
  object
• Inheritance enables the attributes and operations
  of a class to be inherited by all subclasses and
  the objects that are instantiated from them
• Polymorphism enables a number of different
  operations to have the same name, reducing the
  number of lines of code required to implement a
  system and facilitating changes when they are
  made

11
Object-Oriented Software Engineering

• Object-oriented Analysis
• define the classes (objects) that represent the
  problem to be solved
• the manner in which the classes relate to and
  interact with one another
• the inner workings (attributes and operations) of
  objects
• the communication mechanisms (messages) that
  allow them to work together
• Object-oriented Design
• the definition of a multi-layered software
  architecture
• the specification of subsystems that perform
  required functions and provide infrastructure
  support
• a description of objects (classes) that form the
  building blocks of the system
• a description of the communication mechanisms
  that allow data to flow between layers,
  subsystems and objects
• in summary system design, object design, human
  interface design, data management design and task
  management design

12
Object-Oriented Software Engineering

• Steps in Object Oriented Design
• 1. Identify objects
• Consider main concepts and extract the objects
  concerned. Also, interviews, documentation etc
• 2. Determine attributes
• Consider the characteristics that distinguish an
  object (its state)
• Need to prevent redundancies e.g. if we have the
  attribute, BooksOnLoan we do not need
  NumberOfBooksOnLoan as this can be calculated.
• 3. Determine the services for the attributes
• Typically, creation, updating, destruction are
  standard
• Services that provide information on the state of
  an object. These may involve some processing e.g.
  a calculation. This is of course hidden to the
  object requesting the service. (It could be a
  table look up or a calculation for all it knows)

13
Object-Oriented Software Engineering

• 4. Determine the object hierarchy
• Search for relations between objects
• what inherits from what depends on the usage.
  E.g. ReferenceBook and Journal may not be
  subtypes of non-fictional since they will not
  have the service Borrow
• Advantages of the Object Oriented Approach
• It is a natural way to look at things
• Focuses on structuring the problem rather than a
  solution to it
• There is a direct mapping from the requirements
  to design to implementation. The object hierarchy
  from requirements analysis is the basis for
  design and then implementation

14
Object-Oriented Software Engineering

• Flexibility - Easy to add specialisations e.g. a
  class MusicBook, as it simply inherits
  attributes and services from, say,
  Non-Fictional. New attributes or services can
  be easily added.
• Ease of Reuse.
• Traditional techniques identify functions rather
  than objects. Functions change but objects tend
  to stay the same.
• Inheritance allows new objects to be added as
  specialisations, so that class libraries can be
  created and easily added to
• Encapsulation means information hiding,
  abstraction, high cohesion, low coupling and
  therefore easy maintenance

15
Object-Oriented Software Engineering

• Object-oriented Testing
• the nature of OO systems changes both testing
  strategy and testing tactics
• Review OOA and OOD models for correctness
• Review OOA and OOD models for consistency
• Unit testing class testing
• the smallest testable unit is the encapsulated
  class or object
• testing of conventional software tends to focus
  on the algorithmic detail of a module and the
  data that flows across the module interface
• class testing is driven by the operations
  encapsulated by the class and the state behaviour
  of the class

16
Object-Oriented Software Engineering

• Object-oriented Testing
• Integration testing
• OO software does not have a hierarchical control
  structure, conventional top-down and bottom-up
  integration strategies have little meaning
• integrating operations one at a time into a class
  is often impossible because of the direct and
  indirect interactions of the components that make
  up the class
• the use of drivers and stubs as replacement
  operations is to be avoided when possible
• Thread- based Testing integrates the set of
  classes required to respond to one input or event
  for the system. Each thread is integrated and
  tested individually.Regression testing is applied
  to ensure that no side effects occur

17
Object-Oriented Software Engineering

• Use-based Testing begins the construction of the
  system by testing those classes (called
  independent classes) that use very few (if any)
  of server (other) classes. After the independent
  classes are tested, the next layer of classes,
  called dependent classes, that use the
  independent classes are tested. This sequence
  continues until the entire system is constructed
• Validation Testing
• focuses on user visible actions and user
  recognizable outputs from the system (like
  conventional validation)
• the use-cases provide scenarios that have a high
  likelihood of uncovering errors in user
  interaction environments
• test cases may be derived from the object
  behaviour model and from event flow diagram

18
Object-Oriented Modelling

• Object Models
• Object models describe the system in terms of
  object classes
• An object class is an abstraction over a set of
  objects with common attributes and the services
  (operations) provided by each object
• Various object models may be produced
• Inheritance models
• Aggregation models
• Service models

19
Object-Oriented Modelling

• Object Models
• Natural ways of reflecting the real-world
  entities manipulated by the system
• More abstract entities are more difficult to
  model using this approach
• Object class identification is recognised as a
  difficult process requiring a deep understanding
  of the application domain
• Object classes reflecting domain entities are
  reusable across systems
• Object Class Notation

20
Object-Oriented Modelling

• Inheritance Models
• Organise the domain object classes into a
  hierarchy
• Classes at the top of the hierarchy reflect the
  common features of all classes
• Object classes inherit their attributes and
  services from one or more super-classes. these
  may then be specialised as necessary
• Class hierarchy design is a difficult process if
  duplication in different branches is to be avoided

21
Object-Oriented Modelling
Library Class Hierarchy
22
Object-Oriented Modelling
User Class Hierarchy
23
Object-Oriented Modelling

• Multiple Inheritance
• Rather than inheriting the attributes and
  services from a single parent class, a system
  which supports multiple inheritance allows object
  classes to inherit from several super-classes
• Can lead to semantic conflicts where
  attributes/services with the same name in
  different super-classes have different semantics
• Makes class hierarchy reorganisation more complex

24
Object-Oriented Modelling
Multiple inheritance
25
Object-Oriented Modelling

• Object Aggregation
• Aggregation model shows how classes which are
  collections are composed of other classes
• Similar to the part-of relationship in semantic
  data models
• Object Assocition
• shows how classes are interrealated, e.g.
  Lecturer teaches Module, 1M.
• Class Diagram
• shows inheritance, association, aggregation and
  multiplicity between classes

consists of
1..
Deck
Card
26
Unified Modelling Language Notations

• Aims to address the lack of standardisation in
  notation and process among the object-oriented
  methodologies by combining the best elements of
  the main object-oriented methodologies while at
  the same time reflecting best practices in
  industry
• started in the mid-90s by James Rumbaugh (OMT)
  and Grady Booch later joined by Ivar Jacobson
  (Objectory)

27
Unified Modelling Language Notations

• Class
• Example

28
Unified Modelling Language Notations

• Object
• Example

29
Unified Modelling Language Notations

• Association
• Example

30
Unified Modelling Language Notations

• Multiplicities Examples

31
Unified Modelling Language Notations

• Aggregation Example

32
Unified Modelling Language Notations

• Inheritance Example

33
Unified Modelling Language Notations

• Class diagram
• Draw a class diagram to link the following
  classes using aggregation, inheritance and
  multiplicity where appropriate
• Zoo, Animal, Bird, Mammal, Reptile, Cage, Keeper
• (class exercise)

34
Unified Modelling Language Notations

• Class diagram
• Write a brief description of the following class
  diagram (class exercise)

35
Unified Modelling Language Notations

• Class diagram
• Answer
• A lecturer teaches at least on module. Each
  module is taught by one lecturer, and may be
  studied by zero or more students. A student must
  study at least one module, and may study several.
  A module consists of lectures, possibly
  tutorials, and at least one assessment. Both
  coursework and exam are types of assessment.

36
Unified Modelling Language Notations

• Use case diagram Example

37
Unified Modelling Language Notations

• Sequence diagram Example

38
Unified Modelling Language Notations

• Collaboration diagram

39
Unified Modelling Language Notations

• State diagram

Balloon color volume state blowup() letairout()