Introduction to Object-Orientation (O-O) & The Unified Modelling Language (UML)

1. 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. Benefits of Object-Orientation • 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: • Take into account the organisational context in which the software will work, defines what the system will do - systems analysis. • Designing software to meet needs identified in the analysis - systemsdesign. • Produce, or code, the system systemsimplementation. Very simplified view of what is called the Systems Development Life Cycle (SDLC). Analysis and design is very difficult, typically involves: • Start with the ‘big picture’, or ‘big problem’ • Dividing this into a number of smaller ‘problems’. • 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. • 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. Rationale for OOLets design IS to mirror the ‘real world’ • 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.

13. Rationale for OOLets design IS to mirror the ‘real world’ • 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.

14. Rationale for OOObject Reuse: Plug & Play Software • 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?

15. 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

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. What is the UML? • 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

20. What is the UML? “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)

21. Our Method for the Module • Understand the problem (the case) well ie, analysis • Activity diagrams (not covered on this module) • UML Use Case Diagrams (modelling) • Use Case Scripts • UML Classes and Class Collaboration Diagrams • UML Sequence Diagrams and State Machine Diagrams • Produce OO code • Implementation diagrams (not covered on this module)

22. 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

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?