introduction to object-orientation (o-o) & the unified modelling language (uml)

1

StaffordshireUNIVERSITYSchool of Computing

Slide: 1Introduction to O-O

Introduction toObject-Orientation (O-O)

&The Unified Modelling Language (UML)

2



Lecture Objectives

History of (O-O) programming languages

Benefits of Object-Orientation

The Software Development Life-Cycle (SDLC)

Overview of the UML

Relationship between the UML and the SDLC

Critique of O-O and the UML

Explain UML Modelling Process

3



History of (O-O) Programming Languages

Machine Code and assembly languages

High Level programming language FORTRAN (FORMula TRANslation) COBOL (COmmon Business Oriented Language).

ALGOL (ALGOrithmic Language) to SIMULA

Smalltalk-80, Kay and the Palo Alto Research Centre (PARC).

Eiffel, Bertrand Mayer, 1986.

C, from Kernighan and Dennis Ritchie at Bell Labs (now part of AT&T).

Bjarne Stroustrup “C with classes”, to C++.

Patrick Naughton. and James Gosling, Java. 1990s.

Microsoft, C#.

Three mainstream O-O based languages in use today: C++, C# and Java.

4




Mirrors the way that entities in real world behave

Building complex systems from component parts

Ability to store and reuse objects in multiple systems, hope of reducing development cost and time.

We can also learn more about the benefits of the O-O approach by considering that programming, or coding, is just one part of the software development life-cycle.

5



The Software Development Life-Cycle

The process of developing good software based systems always has three essential parts:

1. Take into account the organisational context in which the software will work, defines what the system will do - systems analysis.

2. Designing software to meet needs identified in the analysis - systems design.

3. Produce, or code, the system systems implementation.

Very simplified view of what is called the Systems Development Life Cycle (SDLC).

Analysis and design is very difficult, typically involves:

1. Start with the ‘big picture’, or ‘big problem’

2. Dividing this into a number of smaller ‘problems’.

3. Each problem is then divided again and so on until we have a set of problems that are small enough to fully understand and solve - functional decomposition.

4. Reintegrate all the separate ‘solutions’ into a whole unified system- fits very well with the O-O approach of building software from smaller blocks.

6



The UML

Early (pre release) versions of the UML were simply a pooling of the ‘three amigos’ notations for modelling a software system.

Later refined to avoid repetition and incorporate work from other software modellers: Jim Odell, activity diagrams;and Brian Selic, work on real-time systems.

The Unified Modelling Language (UML) is a standard language for writing software blueprints. The UML may be used to visualize, specify, construct and document the artefacts of a software intensive system. (Booch, et al., 1999, p. 13).

UML has since been adopted by the Object Management Group (OMG).

Sale of Rational to IBM for $2.1 billion in late 2002.

UML is also supported by a number of Computer Aided Software Engineering (CASE) tools.

7



The UML and the SDLC

UML Provides Methods to support us through the Systems Development Life Cycle (SDLC.

The UML inevitably imposes certain ways of going about some tasks in the SDLC. It is not a method. It does not describe a process for specifying, designing and implementing software systems. Rather, the UML is a modelling language for describing software systems.

However, there are methods which support the entire SDLC, and which incorporate the UML as a central idea.

Rational Unified Process (RUP), a comprehensive state-of-the-art method that spans the first ‘visions’ of a system right through to its ongoing maintenance.

RUP is relatively new and is gaining in popularity across the world and seems set to become a prominent method for delivering O-O based software systems.

8



Critique of Object-Orientation and the UML

Bad: Complexity of the UML and modern O-O software development environments.

Contrary to the whole idea of O-O, its concepts are not obvious and can be difficult to understand.

Some argue that computer systems are conceptually different to the types of system we find in the physical world so the whole basis for the O-O approach is fundamentally ill-conceived.

O-O techniques have also come in for criticism from some highly experienced software engineers, who began their careers in the days of FORTRAN and COBOL.

They believe that the basic principles of O-O based software engineering are essentially no different to that of structured software engineering.

In other words, they argue that the O-O approach is just a ‘different’ way of doing things, not necessarily a better way of doing things.

9



Critique of Object-Orientation and the UML

Another problem with O-O based software engineering is simply the legacy of structured programming.

Many software engineers have no desire to change.

There are also many ‘semi’ O-O languages in widespread use today.

JavaScript (which also has C as its ancestor) is still the dominant client side web scripting language.

Likewise, PHP (again based on C) is a mainstream server-side web scripting language, and has growing popularity amongst eCommerce developers.

10



Another Perspective

11



Setting the Scene for OOLets go back to the late 80s/early 90s

The information age: People/businesses becoming (increasingly) dependent on IS ie, IS becoming integrated into the ‘real world’

IS becoming extremely complex

Demands for cross platform/vendor interoperability

Many people ‘working together’ on big IS projects

Demand for shorter development times

Lots of buggy software emerging

12



Objects exist within (virtual) reality. Various objects exist eg, cars, and a particular car is said to be an instance of the class ‘car’.

Classes have attributes that are largely independent of time eg, a car might have a ‘manufacturer’ attribute with the value “Ford”.

Individual objects have states that span particular periods of time eg, a particular instance of the class car may be ‘for sale’ or ‘broken’.

Classes may be aggregated or composed from other classes eg, a car has; a body, some wheels (usually four) and an engine.

Rationale for OOLets design IS to mirror the ‘real world’

13



Classes may be refinements of other classes, eg ‘sports cars’ and ‘limousines’ are both classes that are refinements of the super (or stereotypical) class ‘car’. This type of class linking is known as inheritance (and is sometimes referred to by its inverse, generalisation).

Classes include in their specification a particular set of operations (implemented as methods) eg, cars can be bought (eg, by objects of class ‘customer’ in a car retailing ICT system) but cars cannot be ‘credit checked’ like customers. This idea that objects have intrinsically related operations is a feature of encapsulation.

Classes may be related to other classes eg, cars can be driven on roads but not rivers. This type of object linking is known as association.

Rationale for OOLets design IS to mirror the ‘real world’

14



Greater interoperability

Easier for teams to work together?

Less bugs?

Greater flexibility: objects change infrequently while processes and procedures that relate to them change (increasingly) frequently

Quicker development/lead times?

Market in software objects just like hardware components?

Rationale for OOObject Reuse: Plug & Play Software

15



Lecture Objectives




Overview of the UML



16



What is Special/Different about OO? Encapsulation

Person Shop Assistant

A sandwich please

£2 please

17



What is Special/Different about OO? Polymorphism

Person Friend

A sandwich please

A sandwich

18



What is Special/Different about OO? Inheritance

Animal

19



Developed by the three ‘amigos’: Booch, Rumbaugh & Jacobson

Unified the earlier (software) modelling devices they developed individually

Owned by the Object Management Group (OMG)

Based on OO principles

Has nine types of diagram (we will be covering only three of them)

“Use case” driven

What is the UML?

20



“The Unified Modelling Language (UML) is a standard language for writing software blueprints. The UML may be used to visualize, specify, construct and document the artefacts of a software intensive system.” (Booch, et al., 1999, p. 13)

“The Unified Modelling Language (UML) helps you specify, visualize, and document models of software systems, including their structure.” (OMG, 2002)

“The de facto standard in this domain .” Hunt (2000, p. 4)

What is the UML?

21



Our Method for the Module

1. Understand the problem (the case) well ie, analysis

2. Activity diagrams (not covered on this module)

3. UML Use Case Diagrams (modelling)

4. Use Case Scripts

5. UML Classes and Class Collaboration Diagrams

6. UML Sequence Diagrams and State Machine Diagrams

7. Produce OO code

8. Implementation diagrams (not covered on this module)

22



Lecture Objectives




Overview of the UML



Explain UML Modelling Process

23



Self-test Questions

What type of people might be involved in producing use case diagrams?

What are often cited as being the benefits of use case diagrams, over and above, more technical notations such as ERDs and DFDs?

What is an actor, and how is this different from a (type of) person who might use the system?

What are the boundary and title on a use case diagram and why are they important?

What is a use case?

What is the difference between the uses and extends type of interaction?

What are the common ways of identifying the use cases for a system design?

introduction to object-orientation (o-o) & the unified modelling language (uml)

Documents