COMP209
Object Oriented Programming
System Design
Mark Hall
Introduction
• So far we’ve looked at techniques that aid in designing
quality classes
• To implement a software system successfully requires
planning, design and testing
For larger projects, the amount of time spent on planning and design is often much greater than actual coding
• If you spend most of your time keying in code and
fixing bugs, you can cut down on total time spent by
concentrating more on the planning and design phase
Introduction
• The techniques we are going to look at are the
domain of the fields of Software Engineering
and Systems Analysis and Design
– We’ll take a look at some simple techniques and
processes
– COMP314 delves deeper
Software Engineering
• Software engineers model parts of the real world in software
– Models can be abstract and complex, so are recorded and made visible in documents. This is more useful to other developers than hard to understand code
– Modelling and documentation is as important in the SE process as programming
• Many different approaches, one common idea:
– Decomposition of a complicated problem into less complicated parts
Software Engineering
• Primary objective: produce quality software products
• Quality SE product is
– On time – Within budget – Functional – User friendly – Bug free – Flexible – AdaptableSoftware Process
• A software project usually starts because a customer
has a problem and will pay money to have it solved
• US Dept. Defense was an early proponent of a
formal process for software development
A formal process identifies and describes different phases
of development + guidelines on how to carry out the
phases
The Software Lifecycle
• Many software engineers divide the process into five phases
(referred to as the Software Lifecycle):
– Analysis—decide what the project is supposed to accomplish
• Output: a requirements document
– Design—develop a plan for how to implement the system
• Output: description of classes and methods, with diagrams showing relationships among classes
– Implementation—write and compile program code
• Output: completed program (all classes and methods implemented)
– Testing—run tests to verify that program runs correctly
• Output: report describing tests and their results
– Deployment—release program and install for use
The Waterfall Model
• In the early 1970s, software engineers had a
very simple visual model of these phases
AnalysisDesign
Implementation Testing
Deployment
One phase runs to completion, its output spills over to the next phase, and the next phase begins
The Waterfall Model
• When rigidly applied, the waterfall model did not work
– Difficult to come up with perfect requirements specification – Common to discover requirements problems during the
design phase
– Design problems often come to light during implementation – Many bugs found during testing—often fatal problems that
could only be fixed by starting again! – Unhappy customers :-(
Spiral Model
• Developed in the late 1980’s to address shortcomings
in the standard waterfall process
– Iterative in nature
• “Spiral”
– Phases (perhaps like the waterfall) are performed in each iteration to develop software that is not necessarily the final product
– Construction of prototypes in early iterations
– When intermediate system is done, the project is evaluated to see if further development should be done
Spiral Model
• Driven by risk
– Risk of failure is high for large complex systems
– Eg. it may not be known whether the system can be produced with the resources that can be brought to bear
• In first turn of spiral developers try to resolve this question
– After each turn of the spiral new risks come to light, and a next turn is planned to resolve them
– In later turns, the software prototypes begin to look more an more like finished products
– Along the way, the original requirements might have been modified so that the final system contains only a portion of what was originally intended – ie, that portion for which the risks were overcome
Extreme Programming
• Even complex development processes with many
iterations have not always met with success
• In 1999 Kent Beck introduced Extreme Programming,
a development methodology that strives for
simplicity
– Cuts out most of the formal trappings of traditional
development methodologies
Extreme Programming
• 12 “Commandments” of Extreme Programming:
1. Realistic planning—Meet with coders, managers, and the customer each week to schedule tasks for the next phase. Update the plan regularly
2. Small releases—Put a simple system into production quickly, then release new versions on a short cycle
3. Metaphor—Create an analogy that expresses how the parts of the new system work
4. Simplicity—Design everything to be as simple as possible instead of preparing for future complexity
Extreme Programming
• 12 “Commandments” continued
5. Testing—Write test programs that assure every portion
of the code runs flawlessly before attempting a new task
6. Refactoring—Restructure the system continuously to
improve the code and eliminate duplication
7. Pair programming—Write all code with two
programmers at one machine
8. Collective ownership—Permit anyone on the team to
change code anywhere in the system at any time
Extreme Programming
• 12 “Commandments” continued:
9. Continuous integration—Whenever a task is completed, build the entire system and test it
10. 40 hour week—Don’t cover up unrealistic schedules with bursts of heroic effort
11. On-site customer—Include a real, live user on the team, available full-time to answer questions
12. Coding standards—Use agreed-upon styles and nomenclature to promote easy understanding of what the code does
Extreme Programming
• Many of the extreme programming practices are
common sense
• For this course you will not need a full-fledged
methodology to solve your assignments
• We will take a look at a few modeling techniques
that can help in the analysis and design phase
Analysis
• In the analysis phase of software development, the
task is to discover the requirements for the software
– What is the software supposed to do for its users?
– Behaviour of the software under various conditions
• One tool that can help discover and organize
requirements are Use Cases
Use Cases
• What is a Use Case?
• Use cases document the behaviour of the system from
the user’s point of view
– Express requirements at a high level
• The first step in software analysis is to develop a
sufficient set of use cases
Will also be useful later on for system testing
• E.g. for a word processor:
– Build an index – Insert a picture
Use Cases
• A use case is a sequence of actions that an actor
performs with the help of the system to accomplish a
particular task
• An actor represents
– A role a user can play with regard to a system
– An entity such as another system or a database (outside of the system being modelled)
• Result of use case modelling – all required system
functionality is described in the use cases
Use Cases
• Use cases provide a structured approach to
requirements analysis
– Identify the actors
– For each actor find out
• What they need from the system: that is, what use cases there are which have value for them
• Detail the use case: describe the steps the user would go through with the system to accomplish the usage scenario
• Use cases also provide a good basis for writing
the user manual for the software
Use Cases Example: The University
Library System
• Problem statement :
You have been contracted to develop a software system for a university library. The library currently uses a 1960’s program, written in an obsolete language, for some simple bookkeeping tasks, and a card index, for user browsing. You are asked to build an interactive system which handles both of these aspects on line.
• Vague, but typical of an initial request
University Library – requirements facts
after some investigation
• Books and journals The library contains books and journals. It may have several copies of a given book. Some of the books are for short term loans only. All other books may be borrowed by any library member for three weeks. Members of the library can normally borrow up to six items at a time, but members of staff may borrow up to 12 items at one time. Only members of staff may borrow journals. New books and journals arrive regularly and are sometimes disposed of. The current year’s journals are sent away to be bound into volumes at the end of each year. There may in future be be a requirement for users to be able to extend the loan of a book if it is not reserved. • Borrowing The system must keep track of when books and journals are
borrowed and returned, enforcing the rules described above.
• Browsing The system will allow users to search for a book by topic, author, etc., to check whether a copy of a book is available for loan, and if not, to reserve the book. Anybody can browse in the library
Actors in the Library System
• Users:
– Librarian – Library member – Non-library member• Actors (roles):
– Librarian – BookBorrower – JournalBorrower – BrowserUse Cases in the Library System
• BookBorrower
– Reserve book, Borrow copy of book, Return copy of book, Extend loan
• JournalBorrower
– Borrow journal, Return journal
• Browser
– Browse
• Librarian
Library System Use Case Diagram
BookBorrower
Reserve book
Borrow copy of book
Return copy of book
Extend loan Borrow journal Return journal Browse Update catalogue JournalBorrower Browser Librarian Library System
Documenting Use Cases
• Detail of each use case should be documented
– Use third-person, active voice English
– Use terms from the problem domain (i.e. Those that the
user would understand)
– Say what the system does, not how or implementation
detail
• The basic course of action is the main start-to-finish
path the user will follow under normal circumstances
• An alternative course of action can represent an
infrequently used path, an exception, or error
Borrow copy of book use case
Actor: BookBorrower
Trigger: A potential BookBorrower presents a book to the Librarian Preconditon(s):
The Librarian has successfully identified himself or herself to the library system by entering a valid library staff identification number and password.
Basic course:
A BookBorrower presents a book. The system checks that the potential borrower is a member of the library and that he/she does not already have the maximum permitted number of books on loan. The system records that this library member has this copy of the book on loan. Alternative course(s):
1) If potential borrower is not a member of the library the system refuses the loan. 2) If the library member has the maximum permitted number of books (12 for staff members, otherwise 6) the system refuses the loan
Postcondition(s):
If the loan is successful then the system records the loan against the library member’s record. Otherwise, nothing in the system has changed when this use case ends.
