Changing Perspective

1
Changing Perspective

• From Structured to Object-oriented

2
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

3

• 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

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

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

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

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

8
Model View
Structural View
Implementation View
User View
Environment View
Behavioural View
After Alhir,1998 UML in a Nutshell, OReilly
9
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.

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

11
Behavioural view definition

• Dynamic / behavioural aspects of a problem /
  solution.
• Also known as the dynamic / process / concurrent
  / collaborative view.

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

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

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

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