Object Oriented Design Concepts of OOD Introduction to UML Lectures 19.

Slides:



Advertisements
Similar presentations
Introduction to Object Orientation System Analysis and Design
Advertisements

Chapter 7 System Models.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
A Brief Introduction. Acknowledgements  The material in this tutorial is based in part on: Concurrency: State Models & Java Programming, by Jeff Magee.
Solutions to Review Questions. 4.1 Define object, class and instance. The UML Glossary gives these definitions: Object: an instance of a class. Class:
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System modeling 2.
Inheritance Inheritance Reserved word protected Reserved word super
Object-Oriented Analysis and Design
Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page: Lecture.
Introduction To System Analysis and Design
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
1 SWE Introduction to Software Engineering Lecture 23 – Architectural Design (Chapter 13)
Object Classes In UML. Object Concepts What is an object? How do objects communicate? How is an object’s interface defined? What have objects to do with.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
7M701 1 Class Diagram advanced concepts. 7M701 2 Characteristics of Object Oriented Design (OOD) objectData and operations (functions) are combined 
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Object-oriented Programming Concepts
Itntroduction to UML, page 1 Introduction to UML.
UML and Object Oriented Concepts
Unified Modeling Language
BACS 287 Basics of Object-Oriented Programming 1.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Introduction To System Analysis and design
Programming Languages and Paradigms Object-Oriented Programming.
Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 2: Modelling.
CSCI-383 Object-Oriented Programming & Design Lecture 9.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
System models Abstract descriptions of systems whose requirements are being analysed Abstract descriptions of systems whose requirements are being analysed.
Object Oriented Design and Programming Alan Goude Room: Sheaf 9323.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 18. Review User interface Design principles Design Guidelines.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
Unified Modeling Language, Version 2.0
Introduction To System Analysis and Design
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions.
11 Chapter 11 Object-Oriented Databases Database Systems: Design, Implementation, and Management 4th Edition Peter Rob & Carlos Coronel.
Chapter 7 System models.
System models l Abstract descriptions of systems whose requirements are being analysed.
Pertemuan 19 PEMODELAN SISTEM Matakuliah: D0174/ Pemodelan Sistem dan Simulasi Tahun: Tahun 2009.
Modified by Juan M. Gomez Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
Software Engineering, 8th edition Chapter 8 1 Courtesy: ©Ian Somerville 2006 April 06 th, 2009 Lecture # 13 System models.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Unified Modeling Language* Keng Siau University of Nebraska-Lincoln *Adapted from “Software Architecture and the UML” by Grady Booch.
Fall 2010 CS4310 Requirements Engineering A Brief Review of UML & OO Dr. Guoqiang Hu Department of Computer Science UTEP 1.
An Introduction to the Unified Modeling Language
What is Object-Oriented?  Organization of software as a collection of discreet objects that incorporate both data structure and behavior.
Introduction to UML CS A470. What is UML? Unified Modeling Language –OMG Standard, Object Management Group –Based on work from Booch, Rumbaugh, Jacobson.
Basic Concepts of Object Orientation Object-Oriented Analysis CIM2566 Bavy LI.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Testing OO software. State Based Testing State machine: implementation-independent specification (model) of the dynamic behaviour of the system State:
Slide 1 Systems Analysis and Design With UML 2.0 An Object-Oriented Approach, Second Edition Chapter 2: Introduction to Object-Oriented Systems Analysis.
1 Unified Modeling Language, Version 2.0 Chapter 2.
OOP Review CS 124.
UML (Unified Modeling Language)
Object-Oriented Software Engineering Practical Software Development using UML and Java Modelling with Classes.
1 SWE Introduction to Software Engineering Lecture 14 – System Modeling.
COP 4331 – OOD&P Lecture 7 Object Concepts. What is an Object Programming language definition: An instance of a class Design perspective is different.
Basic Characteristics of Object-Oriented Systems
CSCE 240 – Intro to Software Engineering Lecture 3.
Notices Assn 2 is due tomorrow, 7pm. Moodle quiz next week – written in the lab as before. Everything up to and including today’s lecture: Big Topics are.
Slide 1 Unified Modeling Language, Version 2.0 Object-Oriented SAD.
Engineering, 7th edition. Chapter 8 Slide 1 System models.
Evolution of UML.
Object-Oriented Analysis and Design
Systems Analysis and Design With UML 2
Abstract descriptions of systems whose requirements are being analysed
SNSCT_CSE_PROGRAMMING PARADIGM_CS206
Object Oriented System Design Class Diagrams
UML  UML stands for Unified Modeling Language. It is a standard which is mainly used for creating object- oriented, meaningful documentation models for.
Presentation transcript:

Object Oriented Design Concepts of OOD Introduction to UML Lectures 19

Software Engineering, COMP201Slide 2 Object-oriented Means to organize the software as a collection of discrete objects that incorporate both data structure and behaviour

Software Engineering, COMP201Slide 3 Object concepts We continue to explore the question “what are good systems like?” by describing the object oriented paradigm. We shall answer these questions: –What is an object? –How do objects communicate? –How is an object’s interface defined? –What have objects to do with components? Finally we consider inheritance, polymorphism and dynamic binding.

Software Engineering, COMP201Slide 4 OO reminder Don’t think of what an object holds – but what it will do for you –Consequently no public data members –Think only about the methods An object may represent something in the real world –But often not

Software Engineering, COMP201Slide 5 What is an object? Conceptually, an object is a thing you can interact with: –you can send it various messages and –it will react How it behaves depends on the current internal state of the object, which may change –For example: as part of the object’s reaction to receiving a message. It matters which object you interact with, an object has an identity which distinguishes it from all other objects.

Software Engineering, COMP201Slide 6 Again… What is an object? An object is a thing which has –behaviour, –state and –identity [Grady Booch, 1991]

Software Engineering, COMP201Slide 7 State The state of the object is all the data which it currently encapsulates An object normally has a number of named attributes (or instance variables or data members) each of which has a value Some attributes can be mutable –An attribute ADDRESS other attributes may be constant (immutable) –Date of birth –Identifying number

Software Engineering, COMP201Slide 8 Behaviour The way an object acts and reacts, in terms of its state changes as message passing. An object understands certain messages, it can receive the message and act on them. The set of messages that the object understands, like the set of attributes it has, is normally fixed.

Software Engineering, COMP201Slide 9 Identity - is a little more slippery The idea is that objects are not defined just by the current values of their attributes An object has continues existence –For example the values of the object’s attributes could change, perhaps in response to a message, but it would still be the same object. An object is normally referred to by a name, but the name of the object is not the same thing as the object, because the same object may have several different names

Software Engineering, COMP201Slide 10 Example Consider an object which we’ll call myClock, which understands the messages: –reportTime –resetTimeTo(07:43), resetTimeTo(12:30) or indeed more generally resetTimeTo(newTime) How does it implement this functionality? The outside world doesn’t need to know – the information should be hidden !!! – but perhaps it has an attribute time –Or perhaps it passes these messages on to some other object, which it knows about, and has the other object deal with messages

Software Engineering, COMP201Slide 11 Messages A message includes a selector; here we’ve seen the selectors –reportTime and resetTimeTo A message may, but need not, include one or more arguments Usually for a given selector there is a single “correct” number of arguments

Software Engineering, COMP201Slide 12 Interfaces The object’s public interface defines which messages it will accept regardless of where they come from. An object can always send to itself any message which it is capable of understanding. –Dynamic binding So typically an object has two interfaces: –The public interface (any part of the system can use) –The larger private interface (object itself and other privileged parts of the system can use)

Software Engineering, COMP201Slide 13 Object: classification it depends on the abstraction level and the point of view

Software Engineering, COMP201Slide 14 Object: classification objects with the same data structure (attributes) and behaviour (operations) are grouped into a class each class defines a possibly infinite set of objects

Software Engineering, COMP201Slide 15 Object: classification Each object is an instance of a class Each object knows its class Each instance has its own value for each attribute (state) but shares the attribute names and operations with other instances of the class –also “static” i.e. class variables class encapsulates data and behaviour, hiding implementation details of an object

Software Engineering, COMP201Slide 16 Digression: why have classes Why not just have objects, which have state, behaviour and identity as we require? Classes in object oriented languages serve two purposes: –Convenient way of describing a collection (a class) of objects which have the same properties –In most modern OO languages, classes are used in the same way that types are used in many other languages To specify what values are acceptable

Software Engineering, COMP201Slide 17 Classes and types Often people think of classes and types as being the same thing (indeed it is convenient and not often misleading, to do so). However, it’s wrong! Remember that a class defines not only what messages an object understand! It also defines what the object does in response to the messages.

Software Engineering, COMP201Slide 18 What have objects to do with components? The hype surrounding object orientation sometimes suggests that any class is automatically a reusable component. This, of course, is not true! The first factor is that the reusability of a component is not simply a fact about the component itself, –but depends on the context of development and proposed reuse. Another important factor is that the class structure often turns out to be too fine grained for effective reuse. –In order to reuse a single class you have To be writing in the same programming language and using a compatible architecture

Software Engineering, COMP201Slide 19 Object: inheritance the sharing of attributes and operations among classes based upon a hierarchical relationship class can be defined broadly and then refined into successively finer subclasses each subclass incorporates or inherit all the properties of its super class and its own unique properties

Software Engineering, COMP201Slide 20 Subclass  Superclass A subclass is an extended, specialized version of its superclass. It includes the operations and attributes of the superclass, and possibly some more

Software Engineering, COMP201Slide 21 Object: Inheritance Person NurseDoctor Surgeon Family Doctor single Vehicle Land VehicleWater Vehicle CarAmphibious VehicleBoat multiple

Software Engineering, COMP201Slide 22 Inheritance - warning Don’t abuse inheritance –It is not just a way to be able to access some of the methods of the subclass –A subclass must inherit all the superclass Composition is often “better” than inheritance (!) An object class is coupled to its super-classes. Changes made to the attributes or operations in a super-class propagate to all sub-classes.

Software Engineering, COMP201Slide 23 Object: Polymorphism it means that the same operation may behave differently on objects of different underlying class while being referenced as a superclass OOPL automatically selects the correct method to implement an operation based on the name of the operation (method signature) and the object’s class being implemented

Software Engineering, COMP201Slide 24 Polymorphism - example Vehicle v = null; v = new Car(); v.startEngine(); v = new Boat(); v.startEngine();

Software Engineering, COMP201Slide 25 Dynamic binding Object sending message to itself thingsICanDo:= emptyCollection for each duty in globalDutiesList if (self.canDo(duty)) then add duty to thingsICanDo else do nothing return thingsIcanDo

Software Engineering, COMP201Slide 26 OO Notation - unification Other methodsBooch ‘91OMT-1OOSE Booch ‘93OMT-2 UML 0.8 UML 0.9 & 0.91 UML 1.0 UML 1.1 OMG Feedback UML Books OMG submission, 1/97 6/96 & 9/96 OOPSLA’95, 10/95 OMG Revision, 9/97 OMG Adoption,11/97

Software Engineering, COMP201Slide 27 UML Unify notations UML is a language for: –Specifying –Visualizing and –Documenting the artefacts of a system under development Authors (Booch, Rumbaugh and Jacobsen) agreed on notation but not able to agree on a single method –This is probably a “good thing” UML has been adopted by the OMG (Object Management Group) as an OO notation standard

Software Engineering, COMP201Slide 28 UML – other influences Meyer – pre and post conditions Harel - statecharts Wirfs-Brock - responsibilities Coleman - message numbering scheme Embley - singleton classes Gamma - patterns, notes Shlaer, Mellor - object lifecycles

Software Engineering, COMP201Slide 29 UML – some notation Object classes are rectangles with the name at the top, attributes in the middle section (“compartment”) and operations in the next compartment. Relationships between object classes (known as associations) are shown as lines linking objects Inheritance is referred to as generalisation. –It uses an open triangular arrow head

UML – example Library system Note that if you avoid “Generalisation” you have a recognisable ER diagram

Software Engineering, COMP201Slide 31 CASE Tools/Workbenches Computer Aided Software Engineering A coherent set of tools to support an SE Method These workbenches may support a specific SE method or may provide support for a creating several different types of system model. There is also at least one meta-CASE tool –A CASE tool to build CASE tools

Software Engineering, COMP201Slide 32 CASE Tool components Diagram editors Model analysis and checking tools Repository and associated query language Data dictionary Report definition and generation tools Forms definition tools Code generation tools Import/export translators

Software Engineering, COMP201Slide 33 CASE Tools - examples DOME - see Rational ROSE – see –A big product –Unix version not so good –Reverse engineering a separate step Together – see –Also big – needs a lot of memory >= 256M –Written in Java – so runs “anywhere” –Instant reverse engineering –On the lab Linux machines ArgoUML – see –Free –Written in Java –Some interesting ideas And many Windows only tools

Software Engineering, COMP201Slide 34 Next Lecture Introductory case study