www.monash.edu.au

IMS1805Systems Analysis

Topic 3: Doing Analysis (continued from previous weeks)

www.monash.edu.au

2

Agenda

• Aim: To extend analysis and model building techniques to include the object-oriented approach

• To show where O-O approaches fit within the world of IS analysis

• To introduce some of the key elements of O-O approaches

• To introduce the concept of the Unified Modelling Language (UML)

www.monash.edu.au

3

1. Background and philosophy of object-oriented analysis/design and UML

• A historical reminder:• The pre-analysis period• The process modelling period• The data modelling period• The soft systems modelling period

• The ‘O-O revolution’ in software• System development as an engineering

science; analysis as a formal method• The ‘production-line’ approach to systems

development

www.monash.edu.au

4

Key elements in the advance of O-O analysis/design techniques and UML

Unification & standardisation of modelling methods

Using objects as a fundamental way of

seeing/understanding the world

Integrating all phases of the systems

development process

Creating capabilities for automating

software development

O-O thinking

UML

O-O languages

O-O CASE tools

The O-O World

www.monash.edu.au

5

O-O thinking: Taking a holistic view - seeing systems as interacting objects

• The separation of data from process: artificial or real? Regrettable or unavoidable?

• Using objects and their interactions as the basis of understanding systems

• The benefits of seeing things as objects:• Objects as building blocks• Modular design; objects as ‘black boxes’• Re-use/multiple use of objects

www.monash.edu.au

6

O-O tools: Integrating analysis design and construction

• Objects in software development• Software re-use and modularity• The point and click model of interface design• Objects and code re-usability• Examples - sorting routines, windows, menus, etc

• The rise of O-O development tools - C++, Java, VB.Net, etc (O-O database?!)

• Analysis, design and construction as an integrated continuous process

• Using objects to unite all levels of system development

www.monash.edu.au

7

Unifying/standardising modelling methods: the quest for a common language

• Historical divide between modelling methods • Desire/need to unify and standardise• UML - Unified Modelling language• O-O as a source of pressure for creation of

UML• O-O as an opportunity for creation of UML

www.monash.edu.au

8

Automating software development: the quest for CASE

• Software development as a production process

• The desire for automation of software development

• CASE: Computer-aided software engineering• The CASE tools industry• Linking O-O integration and modularity to

CASE

www.monash.edu.au

9

The O-O Vision

Visualisation of system as interacting objects

Analysis and specification of system as objects in

UML models

Design and specification of system as objects in UML

models

Construction of system as objects in O-O tools

Linked through shared objects and

shared modelling

language (UML)

www.monash.edu.au

10

Some problems/issues for the vision

• Should the method be made to fit the problem or the problem be made to fit the method?

• Is it easy (or useful/helpful) to think of things as objects?

• Can software development be regarded as an engineering science?

• Can software development be a production-line process?

• How U is UML?• How object-oriented are UML-based O-O

approaches to analysis and design?

www.monash.edu.au

11

2. Fundamentals of O-O thinking

• Learning the O-O language• Objects and object classes• Object attributes and object states• Object hierarchies and inheritance• Object behaviours and methods• Encapsulation and information hiding• Polymorphism and dynamic binding

• Note the points of similarity with non-O-O methods – same concepts, different language

• Note the points of difference with non-O-O methods – new concepts, new ways of seeing

www.monash.edu.au

12

Objects and object classes

• System components are seen as objects which interact with one another

• System objects can be grouped/categorised according to certain common shared features

• Object class is a category/grouping of similar objects

• An object class is a template, not a collection of objects; it defines the features of that object class

• Objects belong to a particular object class if they have the features of that object class

• (Relate to entities and instances in data modelling

www.monash.edu.au

13

Object attributes and object states

• Attributes = information about an object• State = a specific combination of attribute

values for an object• For example:

• A ‘Student’ object may have attributes: name, ID, course, no. of credit points of study completed

• A ‘Student’ might take one of three states:• ‘New student’: if no. of points completed = 0• ‘Current student’: if no. of points completed >0 and <144• Completed student’: if no. of points completed = 144

• (Relate to attributes of entities in data modelling)

www.monash.edu.au

14

Object behaviours, methods and messages

• All objects have behaviours – things which they can do (eg a ‘student’ object would be able to perform a behaviour called ‘enrolling’)

• All object behaviours are carried out through the use of particular methods (think of it as a specific implementation of a behaviour) (eg all student objects can enrol, but they may use different methods

• Messages are information sent to an object which trigger its behaviours

• (Relate to processes and data flows in process modelling)

www.monash.edu.au

15

Object hierarchies and inheritance

• Object classes can be arranged into a hierarchy, with more general (abstract) classes at the top, broken into more specific classes at the lower levels

• Objects at the lower levels of the hierarchy inherit all the attributes and methods of the objects above them

Student

New student Current student

BIS student BComp student … etc… etc

www.monash.edu.au

16

Encapsulation and information hiding

• Encapsulation means that all objects combine both data and process elements (ie attributes and methods)

• Information hiding means that although an object may encapsulate many attributes and behaviours, they are designed so that we can deal only with the aspects we are interested in – ie they are ‘black boxes’, which do things without us knowing (or caring) how

www.monash.edu.au

17

Polymorphism and dynamic binding

• Polymorphism means that different object classes can interpret the same message in different ways

• Dynamic binding means that the interpretation of a message is done when the message is received by the object; therefore a programmer can write the code to send a message, without caring about how different objects may have to interpret it

• (Both these are technical and software-based; don’t worry about them at this stage – but don’t be thrown by them if you see them in books!)

www.monash.edu.au

18

3. Fundamentals of UML

• What do we want a modelling language to do?• System visualisation/understanding• System specification• System construction• System documentation

• Conflict between simplicity and sophistication/ range of uses

• Conflict between standardisation and suitability for particular needs

www.monash.edu.au

19

The UML ‘family’ of models

• Grew out of the need to standardise many varied O-O diagramming methods (63 ‘official’ O-O methods identified in 1995!)

• Initially brought together key features of three popular sets of O-O methods (version 1.0, 1996)

• Evolved and expanded to include features of other methodologies (version 1.1, 1.3 and 1.4)

• Enhanced and made more all-embracing (version 2.0, 2004)

• Supported by Object Management Group (www.omg.org)

www.monash.edu.au

20

The Official UML Version 2.0 model types

• Use case diagrams .. represent .. business processes

• Activity diagrams .. represent .. flow in a use case

• Class diagrams .. represent .. object classes an attributes

• Sequence diagrams .. represent .. objects and their time of use

• Interaction overview diagrams .. represent ..object interactions

• Communication diagrams .. represent .. object-to-object messages

• Object diagrams .. represent .. objects and their links

• State machine diagrams .. represent .. object life-cycles (changing states)

• Composite structure diagrams .. represent .. object behaviour

• Component diagrams .. represent .. object libraries

• Deployment diagrams .. represent .. system hardware

• Package diagrams .. represent .. system sub-systems and org units

• Timing diagrams .. represent .. timing of object interactions

www.monash.edu.au

21

The Official UML Version 2.0 model types

• Note the use of diagramming forms which are not O-O!

• Note the overlap/similarities with some process and data modelling methods

• Note similarity in basic diagramming forms – events/sequence/things/interactions/hierarchy/etc

• Which ones do you want to know about?• Which ones might I ask you about in the

assignment/exam?• See next week’s lecture

www.monash.edu.au

22

Summary

• O-O approaches are a different way of approaching the task of analysing a system – basic idea is the same, but we perceive different aspects of the system

• Aim is to link analysis better with O-O implementation tools and technologies

• Much overlap with process and data models, but greater integration of these concepts and a new language to describe it

• UML aims to standardise and unify modelling approaches; closely linked to O-O, but in fact not purely O-O in its approach