WKES2304: Objectoriented Modelling

1
WKES2304 Object-oriented Modelling
2
General information

• Lectures and Tutorials
• Monday Friday 8 850 am
• Friday 9 950 am
• Venue DK1
• Consultation Time
• Wednesday 200 pm 400 pm
• Thursday 200 pm 400 pm
• Lecture Notes Pro-forma

3

• Allocation of marks -
• 50 Final Exam
• 20 MidSem Test
• 20 Group Project
• 10 Tutorials Participation in Class
• 80 attendance required
• lt 80 (3 times) bar from sitting Final Exam

4
WKES2304 Object Oriented Modelling

• Chapter 1 Introduction

5
Chapter Outline

• Introduction
• What is a model?
• Why we model?
• Four principles of modelling
• Object-oriented Modelling

6
Introduction

• The primary product of a development team
• good software that satisfies the evolving need of
  its users and the business
• To achieve good software, we need to
• deploy s/w that satisfies its intended purpose by
  engaging users in a discipline fashion in order
  to expose the real requirements of the system
• develop s/w of lasting quality by crafting a
  solid architectural foundation thats resilient
  to change
• develop s/w rapidly, efficiently and effectively
  by having the right people, the right tools and
  the right focus
• All of these need a sound development process
  that can adapt to the changing needs of business
  and technology

7

• Modelling
• A central part of all the activities that lead up
  to the deployment of good software
• We build models to -
• communicate the desired structure and behaviour
  of the system
• visualise and control the systems architecture
• better understand the system being built,
  exposing opportunities for simplifications and
  reuse
• manage risk

8
What is a model?

• A model is a simplification of reality
• A model provides the blueprints of a system
• It may encompass detailed plans, as well as more
  general plans
• Every system can be described from different
  aspects using different models
• A model may be
• structural emphasizing the organisation of the
  system
• behavioural emphasizing the dynamics of the
  system

9
Why do we model?

• We build models so that we can better understand
  the system we are developing
• Through modelling, we can achieve -
• a visualisation of a system as it is or as we
  want it to be
• a specification of the structure or behaviour of
  a system
• a template that guides us in constructing a
  system
• a documentation of the decision that we have made

10
Importance of modelling

• We build models of complex systems because we
  cannot comprehend such a system in its entirety
• Through modelling,
• we can narrow the problem we are studying by
  focusing on only one aspect of the system
• the divide and conquer approach
• attack a hard problem by dividing it into a
  series of smaller problems that you can solve
• Using a formal model, a common language is
  provided that can be easily shared with others

11
4 principles of modelling

• The choice of what models to create has a
  profound influence on how a problem is attacked
  and how a solution is shaped
• Every model may be expressed at different levels
  of precision
• The best models are connected to reality
• No single model is sufficient. Every nontrivial
  system is best approached through a small set of
  nearly independent models.

12

• The choice of what models to create has a
• profound influence on how a problem is attacked
  
• and how a solution is shaped
• Choose your models well the models you choose
  will greatly affect your world view
• Ex If building a system through the eyes of a
• Database developer the focus would be on E-R
  models that push behaviour into triggers and
  stored procedures
• Structured analyst the focus will be on models
  that are algorithmic-centric, with data flowing
  from process to process
• Object-oriented developer, the focus will be on
  classes and the patterns of interaction that
  direct how those classes work together
• Each world view leads to a different kind of
  system, with different cost and benefits

13

• Every model may be expressed at
• different levels of precision.
• An analyst or an end user will want to focus on
  issues of what
• A developer wants to focus on issues of how
• Both stakeholders will want to visualise a system
  at different levels of detail at different times.

14

• The best models are connected to reality
• All models intend to simplify reality
• make sure the simplifications do not mask/hide
  any important details
• Represent/show what is important to the affected
  party

15

• No single model is sufficient. Every non-
• trivial system is best approached through
• a small set of nearly independent models.
• nearly independent means having models that can
  be built and studied separately but that are
  still interrelated.
• Depending on the nature of the system, some
  models may be more important than others
• Examples
• In data-intensive systems models addressing
  static design views will dominate
• In GUI-intensive systems static and dynamic
  use-case views are important
• In real-time systems, dynamic process views

16
Object-oriented modelling

• 2 most common ways to approach a model-
• Traditional view an algorithmic perspective
• Contemporary view an Object-Oriented perspective

17

• An algorithmic perspective
• The main building block is the procedure or
  function
• Focus is on issues of control and the
  decomposition of larger algorithms into smaller
  ones.
• Drawbacks
• As requirements change and the system grows,
  systems built with an algorithmic focus turn out
  to be very hard to maintain

18

• An object-oriented perspective
• The main building block is the object or class
• Every object has
• Identity name
• State some data associated with it
• Behaviour things the object can do

19

• Advantages
• Proven to be of value in building systems in all
  sort of problem domains and encompassing all
  degrees of size and complexity
• Most contemporary languages, OS, and tools are
  object oriented in some fashion
• Provides the conceptual foundation for assembly
  systems out of components using technology such
  as Java Beans

20

• Visualizing, specifying, constructing, and
  documenting object-oriented systems is exactly
  the purpose of the Unified Modelling Language
• Take note UML is just a modelling language