Modelling Concepts Roman Kontchakov Birkbeck, University of London - - PowerPoint PPT Presentation

▶
modelling concepts
SMART_READER_LITE
LIVE PREVIEW

Modelling Concepts Roman Kontchakov Birkbeck, University of London - - PowerPoint PPT Presentation

Mar 03, 2024 154 likes •322 views

Information Systems Concepts Modelling Concepts Roman Kontchakov Birkbeck, University of London Based on Chapter 5 and 7 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and Design Using UML, (4th Edition), McGraw Hill, 2010 1

slide-1
SLIDE 1

1

Information Systems Concepts Modelling Concepts Roman Kontchakov

Birkbeck, University of London

Based on Chapter 5 and 7 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and Design Using UML, (4th Edition), McGraw Hill, 2010

slide-2
SLIDE 2

2  Models and Diagrams

 Section 5.2 (pp. 114 – 122)

 What Must a Requirements Model Do?

 Section 7.2 (pp. 181 – 184)

Outline

slide-3
SLIDE 3

3

What is a Model?

 “A model captures a view of a physical system. It is an

abstraction of the physical system, with a certain

  • purpose. This purpose determines what is to be included

in the model and what is irrelevant. Thus the model completely describes those aspects of the physical system that are relevant to the purpose of the model, at the relevant level of detail.” (OMG, 2009)

slide-4
SLIDE 4

4

What is a Model?

Model Program Business

Systems Analysis and Design

Real world Conceptual world Computing world

Coding

slide-5
SLIDE 5

5

Abstraction

slide-6
SLIDE 6

6

Why use a model?

 A model is quicker and easier to build  A model can be used in a simulation  A model can evolve as we learn  We can choose which details to include in a model  A model can represent real or imaginary things from

any domain

 A model allows us to talk, or reason, about the real

thing without actually building it

 Much of software development involves creating and

refining models, rather than writing lines of code

slide-7
SLIDE 7

7

Requirements model

 describes what the software should do  represents people, things and concepts important to

understand what is going on

 shows connections and interactions among these

people, things and concepts

 shows the business situation in enough detail to

evaluate possible designs

 must be organized so as to be useful for designing

the software

slide-8
SLIDE 8

8

What is a Diagram?

 A diagram is a graphical representation of a set of

elements in the model of the system

 Models v Diagrams

 A diagram illustrates some aspect of a system  A model provides a complete view of a system at a

particular stage and from a particular perspective

 Most IS models today are in the form of diagrams, with

supporting textual descriptions and logical or mathematical specifications

 A model usually contains many diagrams – related to one

another in some way

slide-9
SLIDE 9

9

Why use a diagram?

 Natural language is often too ambiguous to be used

for modeling

 Communication + Ambiguity = Confusion !

A large object with one trunk and four legs.

slide-10
SLIDE 10

10

UML Diagrams

 UML 2 defines 13 types of diagrams

 Structure

 Class Diagram, Object Diagram  Component Diagram, Package Diagram  Composite Structure Diagram, Deployment Diagram

 Behaviour

 Use Case Diagram  Activity Diagram, State Machine Diagram

 Interaction

 Sequence Diagram, Communication Diagram  Timing Diagram, Interaction Overview Diagram

See Also: Appendix A – Notation Summary

slide-11
SLIDE 11

11

UML diagrams notation

 A UML diagram usually consists of:

 icons  symbols  paths  strings

Plan Chapter Produce First Draft Revise Draft [satisfied] [not satisfied] Add Exercises Add References to Bibliography

slide-12
SLIDE 12

12

What models/diagrams are good?

 Accurate

 unambiguous, following rules or standards

 Concise

 showing only what needs to be shown

 Complete

 showing all that needs to be shown

 Consistent

 internally and among each other

 Hierarchical

 breaking the system down into different levels of details

slide-13
SLIDE 13

13

Developing models

 During the life of a project using an iterative lifecycle,

models change along the dimensions of:

 abstraction — they become more concrete  formality — they become more formally specified  level of detail — additional details are added

slide-14
SLIDE 14

14

Example: Development of a Use Case model

Iteration 1 Obvious use cases Simple use case descriptions Iteration 2 Additional use cases Simple use case descriptions Prototypes Iteration 3 Structured use cases Structured use case descriptions Prototypes

Assign staff to work
  • n
a campaign Campaign Manager Add a n ew advert to a campaign Chec k campaign budget Find campaign Accountant summar y Print campaign inv
  • ice
«include» «ex tend» «extend» P rint campaign «include» «inc lude» C amp aig n Managem en t A ssign s taff to wo rk on a campaign Campaign Manag er Add a new advert to a campaign Check campaign budge t F ind cam paign Accountant summary Print campaign invoice «include» «extend» «extend» Pr int campaign «include» «include» C amp aig n Man agement Calculate staff bonuses Accountant Add a new staff member Add a new staff grade Change the rate for a staff grade Change the grade for a staff member Staff Management Calculate staff bonuses Accountant Add a new staff member Add a new staff grade Change the rate for a staff grade Change the grade for a staff member Staff Management Calculate staff bonuses Accountant Add a new staff member Add a new staff grade Change the rate for a staff grade Change the grade for a staff member Staff Management Calculate staff bonuses Accountant Add a new staff member Add a new staff grade Change the rate for a staff grade Change the grade for a staff member Staff Management Calculate staff bonuses Accountant Add a new staff member Add a new staff grade Change the rate for a staff grade Change the grade for a staff member Staff Management Assign staff to work on a campaign C ampaign Manager A dd a new advert to a campaign Check campaign budge t Find campaign Accountant summary Print campaign invoice «include» «extend» «extend» Pr int campaign «include» «inclu de» Cam paign Man ag ement Spring Jewellery Campaign 1997 Spring Jewellery Campaign 2001 Spring Jewellery Campaign 2002 Summer Collection 1998 OK Quit Campaign: Campaign Selection Holborn Motors Lynch Properties Yellow Partridge Zeta Systems Client: Yellow Partridge Spring Jewellery Campaign 1997 Spring Jewellery Campaign 2001 Spring Jewellery Campaign 2002 Summer Collection 1998 OK Quit Campaign: Campaign Selection Holborn Motors Lynch Properties Yellow Partridge Zeta Systems Client: Yellow Partridge Spring Jewellery Campaign 2002 OK Quit Campaign: Campaign Selection Holborn Motors Lynch Properties Yellow Partridge Zeta Systems Client: Spring Jewellery Campaign 1997 Spring Jewellery Campaign 2001 Spring Jewellery Campaign 2002 Summer Collection 1998 OK Quit Campaign: Campaign Selection Holborn Motors Lynch Properties Yellow Partridge Zeta Systems Client: Yellow Partridge Spring Jewellery Campaign 1997 Spring Jewellery Campaign 2001 Spring Jewellery Campaign 2002 Summer Collection 1998 OK Quit Campaign: Campaign Selection Holborn Motors Lynch Properties Yellow Partridge Zeta Systems Client: Yellow Partridge Spring Jewellery Campaign 2002 OK Quit Campaign: Campaign Selection Holborn Motors Lynch Properties Yellow Partridge Zeta Systems Client:
slide-15
SLIDE 15

15

Take Home Messages

 Models  Diagrams