Changing Perspective

From Structured to Object-oriented

Food for Thought

• A school play– As perceived by the producer / director

– As perceived by Ms. Kenny (room 4)

– As perceived by Johnny (who plays one of the three little ducks)

• An automated train signalling system– As perceived by the train

– As perceived by the signal

– As perceived by the track

…

• An examination– As perceived by a student

– As perceived by the author(s) of the paper

– As perceived by the external examiner

– As perceived by the examinations office

• A lift– As perceived by the lift

– As perceived by the lift controller

– As perceived by the passenger

Structured Methodologies…

• Focus on the system as a whole.

• Incorporate end-users into their scheme.

• Engage with other systems when necessary.

• Consider the system to be bound.

Object-oriented Methodologies…

• Use a bottom-up approach.

• Consider the system as one of many possible combinations of objects.

• Consider the world, and the system within it, to be a set of interactions between objects.

• The system is scoped, rather than bound.

The Object-oriented View

• A system comprises:– A set of users or user roles.– A set of tasks that each user role performs.– A set of stored objects, which interact with each

other to perform the tasks.– A set of user interface objects, that the user

operates to enact the tasks.

Where Do We Begin?

• We are not using– Context Diagrams

– Data Flow Diagrams

– Entity Relationship Diagrams

• Q: How do we define the scope?• A: We state what user roles we have, and what

tasks they expect the system to perform for them. – i.e. with the Use Case diagram.

Model View

User View

Structural View

Environment View

Behavioural View

Implementation View

After Alhir,1998 ‘UML in a Nutshell’, O’Reilly

User view

• Problem and solution from the perspective of those individuals whose problem the solution addresses.

• Presents goals and objectives of problem owners.

• Presents solution requirements.

• Comprises Use Case Diagrams.

Structural View

• Encompasses static or structural aspects of the problem / solution.

• Also known as the static or Logical View.

• Contains– Class diagrams – specification of how the

system is declared.– Object diagrams – static structure of a system at

a particular time during its life.

Behavioural view definition

• Dynamic / behavioural aspects of a problem / solution.

• Also known as the dynamic / process / concurrent / collaborative view.

Behavioural view contents (1)

• Sequence diagrams – Describe the behaviour provided by a system to

interactors, using classes that exchange messages within an interaction arranged in time sequence.

• Collaboration diagrams – realise components in the system. Convert

sequence diagram information into a set of classes, associations and message exchanges.

Behavioural view contents (2)

• Statechart diagrams– Render states and responses of a class participating in

behaviour– the life cycle of an object.

• Activity diagrams.– renders activities or actions of a class participating in

behaviour.– Can describe behaviour of a class in response to

internal processing– Can show the workflow through the system.

Implementation view

• Also known as the component or development view.

• Contains component diagrams.– Describe the organisation of and dependencies

among software implementation components.– E.g. databases, database schemas and tables.

Environment view

• Also known as the deployment View• Shows structure and behaviour of the

domain in which the solution must be realised.

• Contains deployment diagrams.– describe the configuration of processing

resource elements (e.g. hardware) and the mapping of software implementation components onto them.