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’, O’Reilly

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.