04

  • 4.0 Concepts of Object Technology

    From now on in the module most of the models will involve classes & objects. In this lecture you’ll be reminded of, or learn for the first time, the basic concepts of objects and classes, and the terminology which software developers use when working with them.

    Object Diagram

    What is an Object? In everyday life, and not very precise terms, it is a ‘thing’ that you can recognise. However, in object-oriented technology terms it more clearly defined; it is an abstraction of a ‘real-world’ object. In software terms it is a data block and the functions which a ‘real-world’ object. In OO (Object Orientated) systems, our software is a coherent mass of communicating objects, with new ones being created, old ones deleted, existing ones carrying out operations.

    Objects are the repository of all knowledge within the system, and each object has knowledge about its current state. In the UML each piece of knowledge is called an attribute, each attribute has a name and a value. An object’s state is defined by the values of its attribute(s)

  • 4.1 States, Identities and Behaviors

    States

    An Object’s state is the set of properties that causes it to react in a certain manner to an event. State may be determined by the value of its attributes:

    State Diagram

    Identity

    Each object has a unique identity, even if its state is identical to that of another object, e.g. Three people called J Smith on the same flight but each are unique, and they would have a unique Passport Number.

    Identity Diagram

    Behaviours

    Objects have behaviour, i.e. they do things. An object exists in order to provide behaviour (functionality) to the system. In the UML, each distinct behaviour is called an operation. Object behaviour is determined by a set of operations, where an operation is a request to a specific object to perform some action. Operations access or modify attribute values (states) belonging to an object. All instances of a class can use the operations defined for that class.

    Behaviour Diagram

  • 4.2 Objects

    Objects can be thought of as something of interest to a system/application. This allows developers to programmatically solve problems using a coding method focused on objects and their relationships. Objects in many cases represent “things” which exist in the real world. For example, a program that allows customers to buy books online will use objects representing customers, books and orders. A word processor program will deal with objects representing words and paragraphs. A computer game may deal with objects representing characters and scenes.

    Consequently, objects are characterised by states and behaviours. States are attributes (data) we know about the object, behaviours are procedures (methods) which can be performed by the object. For example:

    A door is an object.
    “Open” and “closed” are states.
    “Open door” and “close door” are behaviours.

    Objects can have a number of different types of relationship (association) with other objects. An OO application involves objects invoking methods of other objects to query/modify attributes.

    Suppose we were building a computer game to run an auto race. What kinds of objects would we see displayed on the screen? Car, Driver, Pit, Finish Line, Time Clock.

    Possible attributes and operations

    Car
    Attributes: carNumber, team, make, noOfLaps, gear, speed
    Operations: brake, changeGear, accelerate, changeDirection

    Driver

    Attributes: name, carNumber, championshipPoints
    Operations: changeCar, updatePoints

    When modelling an object, we only need to model the operations and attributes that are important to the problem

    Encapsulation

    Data Encapsulation hides the way things work and what they know behind an interface, i.e. we know how to use the operations, but not how they work …. ( they are coded.)

    What is my car?
    It is an object that has an engine, transmission and seats and moves along the road.
    The engine and transmission are encapsulated. I work with it via the car’s interface – steering wheel, pedals, brake, gears etc..
    What is the Bank ATM?
    It is an object that gives us access to cash
    The ATM encapsulates this for us. We can only access it through its interface. Bypassing the encapsulation is called Bank Robbery
    If the bank rewrites the ATM software, they don’t have to inform everyone – interface hasn’t changed

    Encapsulation hides information. Hiding the implementation details of an object is called encapsulation or information hiding. Encapsulation protects an object’s internal state from being corrupted by its clients and it protects client code from changes in the object’s implementation.

    Object Summary

    An object has operations and attributes
    Operations determine the behaviour of the object
    Attribute values specify the current state of the object
    An object can represent a concrete item, or a concept.
    An object is an abstraction.
    Only contains the operations & attributes that are important to the problem domain
    An object encapsulates a concept
    Operations have an interface to the object
    Objects associate with each other
    Objects communicate with each other via operations, using the operations’ interfaces. This is what we call sending messages
    An object may be made up of other objects
    An integrated circuit is part of a motherboard, which is part of a computer

    Object Definition

    More formally, an object is something that has:
    State
    An object’s state is implemented with a set of attributes and usually changes over time.
    Behaviour
    Behaviour determines how an object responds to requests from other objects. Behaviour is implemented by a set of operations.
    Identity
    The identity of an object makes it unique. You can use the unique identity of an object to differentiate between multiple instances of a class if each instance has the same state.

  • 4.3 What is a Class?

    The difference between classes and objects can be confusing, however, it is simple. A class is the code the programmer creates and an object is what is created when the computer executes the code for the class, i.e. an object is a particular instance of a class. As an analogy, think of the relationship between a blueprint and a car.

    A blueprint is a template that holds all the details for creating a car, much like a class is a template that holds all the details (code) for creating an object. However, until the car has actually been constructed it does not exist; all that exists is the blueprint for creating the car. This is the same relationship between classes and objects, a class can be thought of as a template that holds all the information for an object, but until the code has been run (instantiated) the object does not exist. The object only comes into existence when the program runs the class and creates an object.

    Class Summary & Examples

    A class is a definition or template for objects:

    A class definition specifies the operations and attributes for ALL instances of the class
    Class definition is a template
    each time it is used it creates an object that:
    has exactly the same structure
    carries out the same operations

    Classes & Objects
    Classes are definitions that enable us to understand all the objects of the class
    Objects are instances of classes.
    Objects have state. (own attribute values)

    For example we could have a class called “City” with objects “Edinburgh” & “Paris”. “City” does NOT exist – we don’t go to City for our weekend break. City is a class (blueprint) that defines what all objects in the city class must have – e.g. a population, grid reference, country. “Edinburgh” & “Paris” on the other hand do exist. They each have a state – their own population, grid reference & country. We can go to Edinburgh or Paris.

    Class - another example

    Class Example

    Each object in the BankAccount class will have values for these attributes and be able to carry out these operations

    Class List

    Class List

    Class List

  • 4.4 Class Diagrams

    Class Diagrams are used throughout the software lifecycle are to document the classes that make up a system. They show features of classes (attributes/operations) and present the static structure of the classes in a system. Additionally class diagrams describe the associations & relationships between the classes in a system and document how classes of a particular system interact with existing class libraries.

    In a Class Diagram each class is given a name and should follow naming conventions, e.g.:

    Noun starting with uppercase
    Recommendation – multiple words joined; each word starting with a capital letter (e.g. CarSharer)
    Meaningful
    short (less than 30 characters)

    The class properties then need to be defined:
    Attributes (initially those that capture interesting object states)
    Attribute names start with lowercase
    Operations (can be delayed till later analysis stages or even till design)
    Operation names start with lowercase

    Examples:

    Class Diagram

    Class Diagram

  • 4.5 Attribute types

    In java variables must be declared before the can be used. A declaration requires that a variable is given a name and it's data-type is specified. The eight primitive data-types which java supports are listed in the following table:

    Keyword Description
    byte Byte-length integer
    short Short integer
    int Integer
    long Long integer
    float Single-precision floating point
    double Double-precision floating point
    char A single Unicode character
    boolean A Boolean value (true or false)

    Example:

  • 4.6 Data Encapsulation

    Encapsulation is the process of wrapping an objects/classes data in a manner that it is hidden from other objects/classes. Objects are able to collaborate through behaviour and attributes which are public, however, objects can also have behaviour and attributes which are private. These are for the object itself to use in performing its responsibilities. Public behaviour may modify private attributes or use private behaviour, for example accessor and mutator methods methods (aka "getters" and "setters"), collaborating objects do not need to know about these.

    The visibility of an attribute relates to its availability to other classes:

    Private (-) : feature is available only within the class that owns that feature
    Public (+) : feature is available to any class associated with the class that owns that feature
    Protected (#) : feature is available within the class that owns that feature and any subtype of the class

    Example:

    Class Diagram

    Class Diagram

    Class Diagram

  • 4.7 Class Modelling

    Class modelling should be approached iteratively with Use Case modelling. Candidate classes emerge from our understanding of use cases. Also, expect knowledge of use cases to develop as a result of class modelling.

    Example of a diagram of a single class:

    Class Example

    Class diagram with multiple classes:

    Class Example

    Relationships exist between classes and are shown using lines or arrows

    Two main types of static relationships are-
    Association (a customer places an order)
    Subtypes (a nurse is a type of employee)

  • 4.8 Associations

    Associations represent relationships between instances of a class (i.e. between objects). In a running object-oriented programming, messages are passed and received to and from instances (objects) of the classes in the system. Where instances of one class pass messages to instances of another class, an association is implied between those two classes.

    Class Example

    Although the commonest associations are between 2 classes (binary associations), higher order associations can be drawn with more than 2 ends. In such cases the ends are connected to a central diamond

    Multiplicity indicates how many objects participate in a given relationship. The multiplicity of an association-end indicates the potential number of objects at that end of an association, which may be linked to a SINGLE object at the OPPOSITE end of the association.

    Class Example

    The multiplicity of an association-end indicates the potential number of objects at that end of an association, which may be linked to a SINGLE object at the OPPOSITE end of the association...

    Class Example

    In this example – the arrows indicate how this relationship should be read in both directions
    ( Always start description with ‘ONE’ ):

    ONE Customer can have zero, one, or many Orders

    ONE Order can only have one Customer

    Rules:
    Multiplicity can be a single number or a range.
    A range is shown <lowest> .. <highest> (e.g. 1 .. 5 or 4 .. 6)
    on its own, * is short for 0 .. * (zero to many – no upper limit)
    If there can be any number of an object associated with another, but there must be at least 1, this would be written 1..*
    Some books say that * means infinity. This is confusing. * just means that no upper limit has been specified.

    In all the associations in the class diagrams in the previous examples the multiplicity at one of the ends (and sometimes both ends) is 1. This does not need to be the case. This does not change the definition already given and repeated below:

    “The multiplicity of an association-end indicates the potential number of objects at that end of an association, which may be linked to a single object at the other end of the association.”

    Class Example

    In this example :

    ONE Customer can have zero, one, or many Orders

    ONE Order can only have one, two or three Customers

    To keep the following example simple it shows Multiplicity from ‘A to B’ ONLY ….. NOT ‘B to A’, however, B to A MUST also always be shown in ALL class Diagrams:

    Class Example

    Example diagram:

    Class Example

    An association can be labeled with a name to indicate the nature of the association.
    The name must start with a capital
    The name should be a verb or a verb phrase
    There should be a filled-in arrowhead to indicate the direction in which the text name should be interpreted.

    Class Example

    One Customer Places zero, one or more Orders

    Note: Labeling (naming) of associations is not essential, and can just clutter up diagrams. In the above case the name is not really needed as the meaning of the association is fairly obvious

    The direction of an association indicates the source and target class of the association. Or, thinking of it another way, if we can we navigate from class A to class B, then A is the source class and B is the target class. Let’s consider the Customer Order association.

    Class Example

    The above diagram implies that:

    An Order class will have as one of its attributes a Customer. So, if we know an Order object, we can get to a Customer object. However the converse is not the case – the Customer class does not have an Order, or collection of Orders, as one of its attributes – so if we know a Customer object we would be unable to, directly, get to an Order.

    An association can be bidirectional, meaning that code can navigate in both directions. If the above association were bidirectional it would mean that a Customer object held information about any Order it had placed, while an Order object still had as one of its attributes a Customer. A bidirectional association is shown by either having an arrow at each end of the association:

    Class Example

    or having no arrows (however having no arrows can also mean that the diagram is not showing navigability):

    Class Example

    From Programming 1:

    Class Example

    Class Example

    Class Example

  • 4.9 Generalisation (Inheritance)

    Generalisation is the other form of relationship, in class diagrams, that we’re going to look at. In object-oriented programming this is usually referred to as inheritance. The UML refers to it as Generalisation. It is where one class is a specialized form of another – sometimes referred to as a “kind of” relationship. Gerneralisation will be covered in more depth in a later lecture.

    Class Example