SD Lecture2 July2012

Modelling Concepts
Based on Chapter 5 Bennett, McRobb and Farmer Object Oriented Systems Analysis and Design Using UML 4th Edition, McGraw Hill, 2010
2010 Bennett, McRobb and Farmer 1
In This Lecture You Will Learn:

What is meant by a model The distinction between a model and a diagram The UML concept of a model
2010 Bennett, McRobb and Farmer
What is a Model
Like a map, a model represents something else A useful model has the right level of detail and represents only what is important for the task in hand Many things can be modelled: bridges, traffic flow, buildings, economic policy
Models and Modelling

Analyst describes information system requirements using a collection of models Complex systems require more than one type of model Models represent some aspect of the system being built The process of creating model helps analyst clarify and refine design Models assist communication with system users
Why Use a Model?

A model is quicker and easier to build than the real thing 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
Why Use a Model?....cont.
Modelling Organizations
Organizations are human activity systems. The situation is complex Stakeholders have different views We have to model requirements accurately, completely and unambiguously The model must not prejudge the solution
What is a Diagram?
Abstract shapes are used to represent things or actions from the real world Diagrams follow rules or standards The standards make sure that different people will interpret the diagram in the same way
40
Author
Reviewer
Typesetter
Printer
An Example of a Diagram
An activity diagram of the tasks involved in producing a book.
Write Chapter
Review Chapter
Revise Chapter [book not complete]
[book complete] Typeset Book
Correct Proofs
Reset Book
Print Book
Author
Reviewer
Typesetter
Printer
Hiding Detail
Write Chapter Plan Chapter Write Chapter Produce First Draft Review Chapter
Revise Draft Revise Chapter [book not [not satisfied] complete] [satisfied] [book complete] Add Exercises Typeset Book Add References to Bibliography Correct Proofs
Reset Book
Print Book
10
Diagrams in UML
UML diagrams consist of:
icons two-dimensional symbols paths Strings
Plan Chapter
Produce First Draft
Revise Draft [not satisfied]
UML diagrams are defined in the UML specification.

[satisfied] Add Exercises
Add References to Bibliography
11
Diagrams vs. Models

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. A model may consist of a single diagram, but most consist of many related diagrams and supporting data and documentation.
12
Examples of Models
Requirements Model
complete view of requirements may include other models, such as a Use Case Model includes textual description as well as sets of diagrams
13
Examples of Models
Behavioural Model
shows how the system responds to events in the outside world and the passage of time an initial model may just use Communication Diagrams a later model will include Sequence Diagrams and State Machines
14
Models Used in Analysis and Design of a System

Requirement Analysis phase models help to define:
Logical models
Provide detail without regard to specific technology
Design phase models help define:

Physical models
Provide technical details Extend logical models
Models Used in Requirement Analysis
Models Used in System Design
Models in UML
A system is the overall thing that is being modelled A subsystem is a part of a system consisting of related elements A model is an abstraction of a system or subsystem from a particular perspective A model is complete and consistent at the chosen level of abstraction
Models in UML
Different models present different views of the system, for example:
use case view design view process view implementation view deployment view (Booch et al., 1999)
19
Developing Models
During the life of a project using an iterative life cycle, models change along the dimensions of:
abstractionthey become more concrete formalitythey become more formally specified level of detailadditional detail is added as understanding improves
20
Development of the Use Case Model

Staff Management
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.
Add a new staff member Staff Management
Add a new staff member Add a new staff grade
Add a new staff grade Change the rate for a staff grade
Acc ountant
Change the rate for a staff grade
Change the grade for a staff member
Acc ountant Change the grade for a staff member Calc ulate staff bonuses
Calc ulate staff bonuses
Staff Management
Add a new staff member Staff Management
Add a new staff member Staff Management Add a new staff grade Add a new staff member Add a new staff grade Change the rate for a staff grade Add a new staff grade Acc ountant
Acc ountant
Change the grade for a staff member
Campaign Selection Campaign Selection
Change the grade for a staff member Calc ulate staff bonuses
Acc ountant Change the grade for a staff member Calc ulate staff bonuses
Client: Campaign Selection Client: Client:
Calc ulate staff bonuses
Campaign: Campaign: Campaign:
Holborn Motors Lynch Properties Holborn Motors Yellow Partridge Lynch Properties Zeta Systems Holborn Motors Yellow Partridge Lynch Properties Zeta Systems Yellow Partridge Zeta Systems
OK OK OK Quit Quit
Quit
Campaign M anagement Assign staff to work on a cam paign
include Campaign M anagement Find campaign
Assign staff to work on a cam paign
include Add a new adv include ert to a cam paign Campaign M anagement
inc lude Find campaign
Assign staff to work on a cam paign
Campaign Manager
include
Add a new adv include ert to a cam paign
Check campaign inc lude budget Find campaign
Campaign Manager
include Add a new adv ert to a cam paign extend Check campaign inc lude budget P rint campaign summ ary extend Check campaign budget Accountant P rint campaign summ ary extend extend Print cam paign invoice extend Print cam paign invoice extend
Campaign Selection Campaign Selection Client: Campaign Selection Client: Client: Campaign: Campaign: Campaign: OK OK OK Quit Quit Quit Holborn Motors Lynch Properties Holborn Motors Yellow Partridge Lynch Properties Zeta Systems Holborn Motors Yellow Partridge Lynch Properties Zeta Systems Yellow Partridge Zeta Systems
Campaign Manager
Accountant P rint campaign summ ary Print cam paign invoice
Accountant
21
Summary
In this lecture you have learned about: What is meant by a model The distinction between a model and a diagram The UML concept of a model
22
References
Booch, Rumbaugh and Jacobson (1999) Bennett, Skelton and Lunn (2005)
(For full bibliographic details, see Bennett, McRobb and Farmer)
23
Development Process

About the Unified Software Development Process How phases relate to workflows in an iterative life cycle An approach to system development Major activities in the development process
25
Unified Software Development Process

Developed by the team that created UML Embodies best practice in system development Adopts an iterative approach with four main phases Different tasks are captured in a series of workflows
Four Phases
Inception Elaboration Construction Transition
27
Phases, Workflows and Iterations

Within each phase activities are grouped into workflows The balance of effort spent in each workflow varies from phase to phase Within phases there may be more than one iteration
28
Project Phases
Inception
Elaboration
Iterations within a phase Construction
Transition
1
Requirements
Analysis
Design
Implementation
Test
Workflows
Size of square relative to time spent on workflows 2010 Bennett, McRobb and Farmer
time
29
Major Activities of the Development Process

Activity
Requirements Capture and Modelling
Techniques
Requirements Elicitation Use Case Modelling Architectural Modelling Prototyping
Key Deliverables
Use Case Model Requirements List Initial Architecture Prototypes Glossary
30

Activity
Requirements Analysis
Techniques
Communication Diagrams Class and Object Modelling Analysis Modelling
Key Deliverables
Analysis Models
31

Activity
System Architecture and Design
Techniques
Deployment Modelling Component Modelling Package Modelling Architectural Modelling Design Patterns
Key Deliverables
Overview Design and Implementation Architecture
32

Activity Techniques Key Deliverables Class Design Class and Object Design Models Modelling Interaction Modelling State Modelling Design Patterns
33

Activity
User Interface Design
Techniques
Class and Object Modelling Interaction Modelling State Modelling Package Modelling Prototyping Design Patterns
Key Deliverables
Design Models with Interface Specification
34

Activity
Data Management Design
Techniques
Key Deliverables
Class and Object Design Models Modelling with Database Specification Interaction Modelling State Modelling Package Modelling Design Patterns
35

Activity
Construction
Techniques
Programming Component Reuse Database DDL Programming Idioms Manual Writing
Key Deliverables
Constructed System Documentation
36

Activity
Testing
Techniques
Key Deliverables
Programming Test Plans Test Planning and Test Cases Design Tested System Testing
37

Activity
Implementation
Techniques
Key Deliverables
Planning Installed System Training Data Conversion
38
Summary
In this lecture you have learned about: The Unified Software Development Process How phases relate to workflows in an iterative life cycle An approach to system development Major activities in the development process
References
Jacobson, Booch and Rumbaugh (1999) Kruchten (2004) Chapter 21 of Bennett, McRobb and Farmer includes more about the Unified Process as well as Agile alternatives
40
Requirements Capture

The distinction between the current and required systems When and how to apply the main fact finding techniques The roles played by users The need to document requirements
42
User Requirements
Need to understand how the organization operates at present What are the problems with the current system? What are the requirements users have of a new system that are not in the current system?
Current System
Much of the current system meets the needs of people who use it Sections of the system no longer meet the needs of the organization Some aspects of the organizations work are not covered by the current system The system can no longer evolve but needs to be replaced
Current Systemcont.
It is important to understand the current system to carry functionality forward into the new system It is also important to understand it so that shortcomings and defects can be corrected in the new system
45
Current System.cont.
Advocates of Agile methods focus on developing the new system and not on extensive analysis of the existing system In the Agile Manifesto they state that they value working software over comprehensive documentation
46
Reasons for Investigating the Current System

Functionality is required in new system Data must be migrated into new system Technical documentation provides details of processing algorithms Defects of existing system must be avoided Parts of existing system may have to be kept We need to understand the work of the users Baseline information about the existing system helps set targets for the new one
New Requirements
Organizations operate in a rapidly changing business environment Organizations operate in a changing technical environment Governments and supra-governmental organizations introduce legislation Organizations merge, de-merge, take-over and get taken-over All this drives the need to replace systems and build new ones
Types of Requirements
Functional Non-functional Usability
49
Functional Requirements
Describe what a system must do Include:
processes interfaces with users and other systems what the system must hold data about
Modelled with Use Case Diagrams. Later will be modelled with other kinds of diagrams that show the structure of the system (Class Diagrams) and its behaviour (Interaction Diagrams and State Machines)
Non-functional Requirements
Concerned with how well the system performs Include:
response times volumes of data security considerations
Documented in Requirements List or in Use Case Model (for requirements that can be linked to specific use cases)
51
Usability Requirements
Concerned with matching the system to the way that people work Sets measurable objectives Include:
characteristics of users tasks users undertake situational factors acceptance criteria for the working system
Documented in Requirements List. May be tested by Prototypes

Fact Finding Techniques

Background Reading Interviewing Observation Document Sampling Questionnaires
Background Reading
Aim is to understand the organization and its business objectives Includes:
reports organization charts policy manuals job descriptions documentation of existing systems
54
Background Reading
Advantages:
helps to understand the organization before meeting the people who work there helps to prepare for other types of fact finding documentation of existing system may help to identify requirements for functionality of new system
55
Background Reading
Disadvantages:
written documents may be out of date or not match the way the organization really operates
Appropriate situations:
analyst is not familiar with organization initial stages of fact finding
Interviewing
Aim is to get an in-depth understanding of the organizations objectives, users requirements and peoples roles Includes:
managers to understand objectives staff to understand roles and information needs customers and the public as potential users
57
Interviewing
Advantages:
personal contact allows the interviewer to respond adaptively to what is said it is possible to probe in greater depth if the interviewee has little or nothing to say, the interview can be terminated
58
Interviewing
Disadvantages:
can be time-consuming and costly notes must be written up or tapes transcribed after the interview can be subject to bias if interviewees provide conflicting information this can be difficult to resolve later
Interviewing
most projects at the stage in fact finding when in-depth information is required
Requires skill to carry out effectively
60
Observation
Aim is to see what really happens, not what people say happens Includes:
seeing how people carry out processes seeing what happens to documents obtaining quantitative data as baseline for improvements provided by new system following a process through end-to-end
Can be open-ended or based on a schedule

Observation
Advantages:
first-hand experience of how the system operates high level of validity of the data can be achieved verifies information from other sources allows the collection of baseline data
Observation
Disadvantages:
people dont like being observed and may behave differently, distorting the findings requires training and skill logistical problems for the analyst with staff who work shifts or travel long distances ethical problems with personal data
Observation
when quantitative data is required to verify information from other sources when conflicting information from other sources needs to be resolved when a process needs to be understood from start to finish
Document Sampling
Aims to find out the information requirements that people have in the current system Also aims to provide statistical data about volumes of transactions and patterns of activity Includes:
obtaining copies of empty and completed documents counting numbers of forms filled in and lines on the forms screenshots of existing computer systems
Document Sampling
Advantages:
good for gathering quantitative data good for finding out about error rates
Disadvantages:
not helpful if the system is going to change dramatically
always used to understand information needs where large volumes of data are processed where error rates are high
66
Questionnaires
Aims to obtain the views of a large number of people in a way that can be analysed statistically Includes:
postal, web-based and email questionnaires open-ended and closed questions gathering opinion as well as facts
67
68
Questionnaires
Advantages:
economical way of gathering information from a large number of people effective way of gathering information from people who are geographically dispersed a well designed questionnaire can be analysed by computer
69
Questionnaires
Disadvantages:
good questionnaires are difficult to design no automatic way of following up or probing more deeply postal questionnaires suffer from low response rates
70
Questionnaires
when views of large numbers of people need to be obtained when staff of organization are geographically dispersed for systems that will be used by the general public and a profile of the users is required
Require skill to design effectively

User Involvement
A variety of stakeholders:
senior managementwith overall responsibility for the organization financial managerswho control budgets managers of user departments representatives of users of the system
User Involvement
Different roles:
as subjects of interviews as representatives on project committees as evaluators of prototypes as testers as trainees on courses as end-users of new system
73
Documenting Requirements
Documentation should follow organizational standards Modelling tools that produce UML models maintain associated data in a repository Some documents will need separate storage in a filing system:
interview notes copies of existing documents minutes of meetings details of requirements
74
Documenting Requirements
Documents should be kept in a document management system with version control Use use-cases to document functional requirements Maintain a separate requirements list Review requirements to exclude those that are not part of the current project
Requirements Analyst Project Initiation Document Elicit requirements Glossary Candidate Requirements Select requirements
Requirements List
Develop use cases
Use Case Model
76
Requirements Team
Use Case Model
Requirements List Project Initiation Document Requirements capture and modelling
Interface Prototypes
Initial System Architecture
Glossary
77
Summary
In this lecture you have learned about: The distinction between the current and required systems When and how to apply the main fact finding techniques The roles played by users The need to document requirements
78
References
Oppenheim (2000) Allison et al. (1996) Usability is covered in more detail in Chapter 16 of Bennett, McRobb and Farmer Chapter A2 shows products of requirements capture and modelling
79

SD Lecture2 July2012

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

SD Lecture2 July2012

Загружено:

Авторское право:

Доступные форматы

Modelling Concepts

In This Lecture You Will Learn:

2010 Bennett, McRobb and Farmer

Models and Modelling

Why Use a Model?

Why Use a Model?....cont.

2010 Bennett, McRobb and Farmer

Revise Chapter [book not complete]

[book complete] Typeset Book

2010 Bennett, McRobb and Farmer

2010 Bennett, McRobb and Farmer

Produce First Draft

Revise Draft [not satisfied]

UML diagrams are defined in the UML specification.

[satisfied] Add Exercises

Add References to Bibliography

Diagrams vs. Models

2010 Bennett, McRobb and Farmer

2010 Bennett, McRobb and Farmer

2010 Bennett, McRobb and Farmer

Models Used in Analysis and Design of a System

Design phase models help define:

Models Used in Requirement Analysis

Models Used in System Design

2010 Bennett, McRobb and Farmer

2010 Bennett, McRobb and Farmer

Development of the Use Case Model

Add a new staff member Staff Management

Add a new staff member Add a new staff grade

Change the rate for a staff grade

Change the grade for a staff member

Calc ulate staff bonuses

Add a new staff member Staff Management

Change the rate for a staff grade

Change the rate for a staff grade

Change the grade for a staff member

Campaign Selection Campaign Selection

Client: Campaign Selection Client: Client:

Calc ulate staff bonuses

Campaign: Campaign: Campaign:

Campaign M anagement Assign staff to work on a cam paign

include Campaign M anagement Find campaign

Assign staff to work on a cam paign

inc lude Find campaign

Assign staff to work on a cam paign

Add a new adv include ert to a cam paign

Check campaign inc lude budget Find campaign

Accountant P rint campaign summ ary Print cam paign invoice

2010 Bennett, McRobb and Farmer

2010 Bennett, McRobb and Farmer

2010 Bennett, McRobb and Farmer

In This Lecture You Will Learn:

2010 Bennett, McRobb and Farmer

Unified Software Development Process

2010 Bennett, McRobb and Farmer

Phases, Workflows and Iterations

2010 Bennett, McRobb and Farmer

Iterations within a phase Construction

Major Activities of the Development Process

2010 Bennett, McRobb and Farmer

Major Activities of the Development Process

2010 Bennett, McRobb and Farmer

Major Activities of the Development Process