Lecture 2 & 3
Content
Software Development Methodologies
Classical Phases in Software Production
The Unified Modelling Language, Version 2.0
Case Study - Nowhere Cars mission statement
Lecture 2
Classes and Objects
It uses the UML to show the relationship
Lecture 2 2021
Classes and Objects
It uses the UML to show the relationship
Lecture 2 2021
It uses the UML to show the relationship
Fig 1-13 (Textbook #1) shows Polymorphism
Software Development Methodologies
A methodology is a systematic way of doing things.
All software, especially large pieces of software produced by many people, should be
produced using some kind of methodology.
Even small pieces of software developed by one person can be improved by keeping a
methodology in mind.
Software Development Methodologies
Large development projects also benefit from:
Documentation
Reduced latency
Improved chances of delivery on time and within budget.
Better communication between users, sales people, managers and developers
Repeatability
More accurate costing
Software Development Methodologies
A good methodology will address at least the following issues:
Planning: Deciding what needs to be done.
Scheduling: Mapping out when things will be done.
Resourcing: Estimating and acquiring the human, software, hardware and other resources
that are needed.
Workflows: The subprocesses within the wider development effort (for example, designing
the system architecture, modeling the problem domain and planning the development
effort).
Software Development Methodologies
Activities: Individual tasks within a workflow,
such as testing a component,
drawing a class diagram,
detailing a use case …
Roles: (developer, tester or sales person).
Artifacts: pieces of software, design documents, training plans and manuals.
Education: Deciding how to train personnel,
(staff, customers, sales people)
CLASSICAL PHASES IN SOFTWARE PRODUCTION
1-Requirements
2-Analysis
3-Design
4-Specification
5-Implementation
6-Testing
7-Deployment
8-Maintenance
CLASSICAL PHASES IN SOFTWARE PRODUCTION
1-Requirements
Discovering what we’re going to achieve with our new piece of software
Business modeling: Understanding the context in which our software will operate.
Functional specification: Deciding what capabilities the new software will have and writing
down those capabilities.
Key Questions
‘What is our context?’
‘What are we trying to achieve?’
CLASSICAL PHASES IN SOFTWARE PRODUCTION
2 - Analysis
Understanding what we’re dealing with.
Before we can design a solution, we need to be clear about the relevant entities, their
properties and their inter-relationships.
Key Questions
‘What entities are we dealing with?’
‘How can we be sure we have the right ones?’
CLASSICAL PHASES IN SOFTWARE PRODUCTION
3- Design
Breaks the system down into
logical subsystems (processes) and
physical subsystems (computers and networks),
decides how machines will communicate,
chooses the right technologies for the job.
Key Questions
‘How are we going to solve the problem?’
‘What hardware and software will we need in the finished system?’
CLASSICAL PHASES IN SOFTWARE PRODUCTION
4-Specification
Describing the expected behavior of our programming components.
Specification can be used in the following ways:
• As a basis for designing test software to exercise the system.
• To demonstrate that our software is correct (this is desirable for life-critical applications).
• To document our software components to the extent that they could be implemented by
third parties.
• To describe how our code can be reused safely by other applications.
Key Questions
‘What rules govern the interfaces between the system components?’
‘Can we remove ambiguity and ensure correctness?’
CLASSICAL PHASES IN SOFTWARE PRODUCTION
5-Implementation
Writing pieces of code that work together to form subsystems, which in turn collaborate to form the
whole system.
Key Questions
‘How can we code the components to meet the specification?’
‘How do we write stylish code?’
CLASSICAL PHASES IN SOFTWARE PRODUCTION
6-Testing
The software must be tested against the system requirements to see if it fits the original
goals.
Key Questions
‘Does the finished system satisfy the requirements?’
‘Can we break the system?’
CLASSICAL PHASES IN SOFTWARE PRODUCTION
7-Deployment
Getting the hardware and software to the end users, along with manuals and training
materials.
A complex process, involving a gradual, planned transition from the old way of working to
the new.
Key Questions
‘What do the system administrators have to do?’
‘How can we educate the end users?’
CLASSICAL PHASES IN SOFTWARE PRODUCTION
8- Maintenance
The software has to stand up to everyday use.
We must find the faults and remove them as quickly as possible, rolling out fixed versions of
the software to keep the end users happy.
Users may discover
deficiencies (things that the system should do but doesn’t),
extra requirements (things that would improve the system).
Key Questions
‘Can we find and fix the faults?’
‘Can we improve the system?’
The Unified Modelling Language, Version 2.0
■ Functional Diagrams
■ Structure Diagrams
■ Behaviour Diagrams
– Developers
■ Grady Booch
■ Ivar Jacobson
■ James Rumbaugh
The Unified Modelling Language
Functional Diagrams Structure Diagrams Behaviour Diagrams
▪ Use-Case Diagrams ▪ Class diagrams ▪ Sequence diagrams
▪ Activity Diagrams ▪ Object diagrams ▪ Behavioural State Machines
Functional Diagrams
■ Use-Case Diagrams
– Capture business requirements
– Illustrates interaction between system and
environment
Functional Diagrams
■ Activity Diagrams
– Illustrate business workflows
Structure Diagrams
■ Class diagrams
– relationship between classes
Structure Diagrams
■ Object diagrams
– Relationships between objects
Behaviour Diagrams
■ Interaction Diagrams ....
– Sequence diagrams
■ Show Time-based ordering and behavior of objects and their activities
Slide 34
Behaviour Diagrams
■ State Machines ...
– Behavioural State Machines (c)
■ Examines behavior of one class/object
Case Study
Nowhere Cars mission statement
Case Study
Nowhere Cars mission statement
Since we automated the tracking of cars at our stores – using bar codes,
countertop terminals and laser readers – we have seen many benefits: the
productivity of our rental assistants has increased 20%, cars rarely go
missing and our customer base has grown strongly (according to our
market research, this is at least partly due to the improved perception of
professionalism and efficiency).
Case Study
The management feels that the Internet offers further exciting
opportunities for increasing efficiency and reducing costs. For example,
rather than printing catalogs of available cars, we could make the catalog
available to every Internet surfer for browsing on-line. For privileged
customers, we could provide extra services, such as reservations, at the
click of a button. Our target saving in this area is a reduction of 15% in the
cost of running each store.
Case Study
Within two years, using the full power of e-commerce, we
aim to offer all of our services via a Web browser, with
delivery and pick-up at the customer’s home, thus achieving
our ultimate goal of the virtual rental company, with minimal
running costs relative to walk-in stores.
Case Study
Even this three-paragraph mission statement contains a lot of information:
history of automation at the company;
customer satisfaction to date;
on-line catalogs and reservations;
privileged and non-privileged customers;
savings history and savings targets;
company end-game (the ‘virtual rental company’).
Case Study
Admittedly, some of the management’s dreams are a long way off (it may be
more than two years before customers are comfortable with virtual rental
stores), but at least we have two good starting points for our investigation:
What services do the company’s stores currently offer?
Which of those services are appropriate for Internet delivery?
Case Study
The fictitious company’s new system is referred to as Coot,
with the Internet facilities available to customers referred to as iCoot.
Case Study
The unique selling point of Nowhere Cars is that they rent specialist cars to
wealthy enthusiasts for extended periods. Since the supply of each kind of car
is limited, customers must turn up at a store when they actually want to rent.
Cars are rented on a first-come, first-served basis and customers can take
their pick from what is currently available.
Case Study
Alternatively, customers who are keen to rent a model of car which is not
available can make a reservation. An assistant will contact the customer
directly when a matching car becomes available; the customer must collect it
within two days (or pay a levy for depriving other customers of the car). As yet,
there are no home delivery or home pick-up services (partly for insurance
reasons). For members, who must register, reservations can be made by
telephone.
To be continued
Modeling with use cases and the use-case diagram
■ a use-case diagram provides a simple, straightforward way of communicating to the users
exactly what the system will do,
a use-case diagram is drawn when gathering and defining requirements for the
system.
■ In this manner, the use-case diagram can encourage the users to provide additional high-
level requirements.
■ A use-case diagram illustrates in a very simple way the main functions of the system and
the different kinds of users that will interact with it.
■ Elements of Use-Case Diagrams (Page 121-122, Textbook #1)
Modeling with use cases and the use-case diagram
Patients, doctors, and management personnel will use the appointment system to
manage appointments,
record availability, and
produce schedules
Modeling with use cases and the use-case diagram
viewing car model details involves
a customer selecting a car model,
requesting its details,
receiving specific information about the car model
Class diagram
A class diagram shows which classes exist in the business (during analysis) or in the system
itself (during subsystem design).
A class diagram shows how objects of these classes can be connected together.
a CarModel has inside it a
CarModelDetails, referred to as its details.
A CarModel has inside it a CarModelDetails, referred to as its
