Object-Oriented Software Engineering

Object-Oriented Software Engineering Dr Zhonglin He University of Ulster

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

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 -> faster development -> higher quality programs • easier to maintain because it structure is inherently decoupled • fewer side effects when changes have to be made

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)

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 Desk’s methods: buy, sell, move

Object-Oriented Software Engineering • Object-Oriented Concepts • An object’s behaviour is described in terms of the operationsprovided 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

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.

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

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.

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

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

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’)

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

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

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

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

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

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

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

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

Object-Oriented Modelling Library Class Hierarchy

Object-Oriented Modelling User Class Hierarchy

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

Object-Oriented Modelling Multiple inheritance

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, 1:M. • Class Diagram • shows inheritance, association, aggregation and multiplicity between classes consists of 1..* Deck Card

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)

Unified Modelling Language Notations • Class • Example

Unified Modelling Language Notations • Object • Example

Unified Modelling Language Notations • Association • Example

Unified Modelling Language Notations • Multiplicities : Examples

Unified Modelling Language Notations • Aggregation: Example

Unified Modelling Language Notations • Inheritance: Example

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)

Unified Modelling Language Notations • Class diagram Write a brief description of the following class diagram (class exercise)

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.

Unified Modelling Language Notations • Use case diagram: Example

Unified Modelling Language Notations • Sequence diagram: Example

Unified Modelling Language Notations • Collaboration diagram

Unified Modelling Language Notations • State diagram Balloon color volume state blowup() letairout()

Object-Oriented Software Engineering