1. Models and Modelling Object-Oriented Analysis David William Brown
Adapted from slides accompanying the book by
David William Brown

2. Models and Modelling Definitions History of Systems Analysis
3. Models as Aid to Understanding
4. Early Business Process Methods
5. Object Oriented Analysis & Design
6. Unified Modelling Language

3. What comes to mind when you hear the word “Model?”
A representation
Looks different
For trying things out
For understanding something
Smaller, simpler Ar
khe same
Made of different

4. Here’s an example of a model:
Q: How do auto designers decide what shape a car should be?
A1: Build one and drive it? NO
A2: Build one and put it in a wind tunnel. CLOSER
A3: Build a MODEL and put it in a wind tunnel. RIGHT

5. It has what it needs for the problem
It has the right shape . . .
So the air will flow around it just like the real thing. In other words:
It has what it needs for the problem
Other Models include:
Maps, House Plans, Program flowcharts
Equations - a “Mathematical Model”

6. Abstraction Definition:
Modelling is actually a form of abstraction when we build something, with the features needed for the problem at hand.
Definition:
The process of focusing on those features that are essential for the task at hand, and ignoring those that are not.

7. The History of Systems Analysis
1960S: Unsystematic, “Seat-of-the-Pants”
Late ’60s: “Output-Oriented”
1970s: Process-Oriented; DFDs
1980s: Data-Oriented; ERDs
SOFT SYSTEMS - RICH PICTURES
1990s: Object-Oriented, OOA&D, OOP.
Earliest methodologies were scientific
Later, methodologies focused on only the business processes.
Object modeling first considers the data in terms of objects, the things people need to know about.

8. Early Business Process Methods
The Systems Development Life-Cycle (SDLC)
Recognized circa 1970
Development follows a pattern
Reproducible
All steps are necessary

9. The Systems Development Life-Cycle (SDLC)
Feasibility Study: Can it be done?
Analysis: What users need system to do
Design: Plan of how the system will do it.
Implementation: Write, Test and Implement the system
Maintenance: Keep the system operational and useful to the users.

10. Structured Methodology
SSADM – Structured Systems Analysis and Design Methodology
Developed by Learmonth & Burchett Management Systems for the British Government in 1980/1.
Provides 3 views of the system
Static: How the data is stored – Logical Data Structures (entity relationship diagram)
Flow and Collaboration: How data moves around the system. Data Flow Diagram.
History and State: How data changes over time – Entity Life History.

11. Entity Relationship Diagram
Static view of data. Each entity represents a table in database modelling.
customer
order
Stock_Item
Each customer may have one or more orders
Each stock item may be on one or more orders.

12. Data Flow Diagrams (DFDs)
Customer
order
valid order 1
Validate customer orderc
D Order
problem orders

13. Entity Life History Customer New Customer Existing Customers
Old Customer – no orders for 6 months
Detail Changes
Account Balance

14. SOFT SYSTEMS METHODOLOGY (SSM)
Peter Checkland uses RICH PICTURES and ROOT DEFINITIONS
Provides a way of reaching insights to help understand unclear problem situations
Guides the analyst/software engineer to view an organisation as a “human activity system”
Problems faced in an organisation are unstructured, messy, different people have their own views or feelings about what is wrong and what might be done. Often this is manifested as a feeling of unease rather than as a clearly stated requirement.
So far so good, general advice, all very sound, but can we do more, provide more structure to this process of designing a problem and base it on more than common sense?
One answer is given by Peter Checkland's Soft Systems Methodology (SMM).
SSM:
Provides a way of reaching insights to help understand unclear problem situations.
Guides the analyst/software engineer to view an organisation as a “human activity system”.
What do we mean by that is, well very often, problems related with human activities cannot be expressed explicitly enough for the analyst or anybody else to be sure of what their solution may be.
As we already discussed, problems faced in an organisation are unstructured, messy and different people have their own views or feelings about what is wrong and what might be done. Often this is manifested as a feeling of unease rather than as a clearly stated requirement.
That is the reason why we need to explore such situations, identify sources of problems, conflicts etc. before we start formally to capture requirements and SSM helps us to do that.

15. source: P.J. Lewis, 'Rich Picture building in the SSM,' European Journal of Information Systems
This is an example of a rich picture in a university setting. You can see there the accommodation office employee crying for help because he is overwhelmed with applications and probably his system is not working up to standard in order to facilitate his work. Also, notice the boundary, it shows clearly the university’s boundary and people or organisations outside the boundary such as competitor universities or university applicants.
So as you see, it is just a picture, a drawing of the situation. A good picture uses nice symbols, it clearly shows the boundaries of the organisation, the conflicts between different people and it just provides as much information about the organisation as possible.

16. Object Oriented Modelling
A Child’s First model
Since birth we have all been using object models

17. Mental Models and our World View

18. These objects… Have attributes Have attribute values
Are capable of behaviour
Exhibit this behavior in response to messages
The child learns to predict and eventually to manipulate its environment

19. Object Oriented Analysis & Design
More closely emulates the way that humans learn
Uses Unified Modelling Language, used for
Visualising Systems
Constructing Systems
Documenting Systems

20. UML There are 9 different UML diagrams
Each emphasises one aspect of a system
Together all models provide a complete description of a system
UML can be used to model a broad range of systems
H/W DATABASES REAL TIME
REAL WORLD S/W

21. Model Types
The User Model View - Use case diagrams show the functionality of a system.
The Static / State Model View - Class/Object diagrams show the static structure of a system.
The Behavioural Model View
- Sequence diagrams show the specification of behaviour.
- Collaboration diagrams show the realisation of behaviour.

22. Model Types The State Change Model View
State diagrams show state of entity over time
Activity diagrams show the activities of participants involved in behaviour.
The Implementation Model View
Component diagrams show the relationship between physical components.
The Environment Model View
Deployment diagrams show the layout of elements of environment and the mapping of solution components onto them.

23. UML - an object-oriented modeling language
a (graphical) language/notation to
analyse systems
(not just software)
create models
not a process or a methodology – it is a toolkit
The art is to choose the correct tool for the job

24. UML diagrams UML describes models with diagrams
UML diagrams use standard set of notational symbols
core symbols are class, state and use case
core relations are association and dependency
symbols may be adorned with additional information about the element
UML provides ‘stereotype’ mechanism for extending the symbol set

25. UML notational symbols

26. use case diagrams (user view)
Package
SimpleWatch
Actor
ReadTime
SetTime
WatchUser
WatchRepairPerson
Use case
ChangeBattery
Use case diagrams represent the functionality of the system
from user’s point of view

27. static structure diagrams (data and methods)
class diagrams show how things are classified and relationships between the classes
object diagrams show how objects (class instances) are related at a particular point in time.
Class
Multiplicity
Association
SimpleWatch
Attributes 1 1 1 1 2 1 2 1
PushButton
state
push() release()
LCDDisplay
Battery
load()
Time
now()
blinkIdx
blinkSeconds()
blinkMinutes()
blinkHours()
stopBlinking()
referesh()
Operations

28. interaction diagrams (message passing between objects)
sequence diagrams show sequencing of interactions
collaboration diagrams show relationship between interacting objects
Object
blinkHours()
blinkMinutes()
incrementMinutes()
refresh()
commitNewTime()
stopBlinking()
pressButton1()
pressButton2()
pressButtons1And2()
:WatchUser
:Time
:LCDDisplay
:SimpleWatch
Message
Activation

29. state diagrams – how systems change overtime
state diagrams show possible state changes of objects in a class and events that cause them
Statechart of the 2BWatch set time functions

30. Activity Diagram- used to model the flow of activities in a procedure
Build House

31. implementation diagrams
Component
Interface
Component Diagram

32. implementation diagrams
Deployment Diagram