程序代写代做代考 assembly algorithm Java database game Fortran data structure FIT9131 Week 9

FIT9131 Week 9
Programming Foundations FIT9131
1
Program design Week 9

FIT9131 Week 9
Lecture outline
2
• Program Design vs Program Coding
• Design Techniques
• Responsibility-driven design • Use cases and scenarios
• CRC cards

FIT9131 Week 9
Design
Programs are written to solve particular problems.
Programs range from small and simple, to large and complex.
Careful design and implementation are needed for successful program development – both are important!
It is important:
• to know about programming when designing
• to know about design when programming (anything more than just a simple program)
3
vs
Programming (Coding)

FIT9131 Week 9
Some interesting Quotes
Hofstadter’s Law:
It always takes longer than you expect, even when you take Hofstadter’s Law into account.
Ninety-Ninety Rule of Project Schedules:
The first ninety percent of the task takes ninety percent of the time, and the last ten percent takes the other ninety percent.
Experience is something you don’t get until just after you need it.
4

FIT9131 Week 9
Programming in the Small
• one person, or a small group, develops all the code • it is possible for one person to understand all
aspects of the project
• typically the focus is on design and development of algorithms
• in computing, an “algorithm” is a step-by-step procedure for performing a task – much like a recipe in a task like cooking
5

FIT9131 Week 9
Programming in the Large
• large amount of code – programs are developed by teams
• not possible for one person to understand all aspects of a project
• team members have a variety of (different) skills
• design decisions often made by different people
than the programmers or maintainers
• the project may have a long life (maintenance done after original developers are long gone)
Major issues are management of project details and communication issues
6

FIT9131 Week 9
Coping with complexity
Machine Language Assembly Language
Fortran, COBOL, C++, Java
Single programmer Teams of programmers
Evolution of
languages
Evolution of
programmers
7

FIT9131 Week 9
Coping with complexity
Modern systems are becoming much bigger in size
Modern systems are becoming much more complex
The relationship between Complexity & Code Size is non-linear (ie. a small increase in complexity can require a large increase in the code size)!
8

FIT9131 Week 9
Coping with complexity : some more interesting quotes
“Adding manpower to a late software project makes it later”
(Brooks, 1975)
“The bearing of a child takes nine months, no matter
how many women you assign to the task” (Brooks 1975)
9

FIT9131 Week 9
From problem to code
Each stage of software development is a modeling process:
Analysis: Design: Implementation:
Maintenance:
10

FIT9131 Week 9
From problem to code
Each stage of software development is a modeling process:
Analysis: modeling the problem
Design: modeling the solution
Implementation: making the model run on the computer (ie. coding)
Maintenance: adjusting and extending the model
The processes are not mutually-exclusive, and are not necessarily performed in a linear manner…
11

FIT9131 Week 9
Objects & Modeling
Objects provide the bases for object-oriented design and coding.
Object-oriented techniques aid the design process :
• Objects are closely related to the way people think, hence making them easier to model/code
• Objects come from the problem domain, representing real entities in the domain (eg. students in a school enrolment system)
12

FIT9131 Week 9
Program design
The main goals of object-oriented program design are to identify:
• classes
• responsibilities of these classes
• relationships between these classes
This is an iterative process.
It is very important to get the program design correct in the first place – otherwise much time will be wasted later in fixing problems in the (typically very costly) implementation/maintenance stages.
13

FIT9131 Week 9
Design methods
Some common design techniques:
• Identification of classes and behaviour from a problem specification.
• Class-Responsibility-Collaboration (CRC) cards
• “Use cases” and scenarios.
A design approach:
• Responsibility-Driven Design – an object- oriented design technique that is driven by an emphasis on behaviour (Wirfs-Brock)
14

FIT9131 Week 9
Identifying classes and behaviour from a specification
15
A useful trick is the “Nouns & Verbs” technique :
1) read through the problem specification
2) pick up all the nouns
• these become potential candidates for Classes in the design
3) pick up all the verbs
• these become potential candidates for Behaviour in the design

FIT9131 Week 9
The “Nouns & Verbs” technique
Example : Let’s say we are to write a program that will manage the accounts for a bank.
Consider the following (simplistic) scenario :
Metropolitan bank offers the following types of accounts to its customers: savings accounts, check accounts, and credit accounts. Customers may deposit money into an account or withdraw money from an account. At the end of each month interest is calculated for each account and added to the account balance. Annual fees are charged to the credit account and deducted from the balance.
16

FIT9131 Week 9
Identification of
Example :
Metropolitan bank offers the following types of accounts to its customers: savings accounts, check accounts, and credit accounts. Customers may deposit money into an account or withdraw money from an account. At the end of each month interest is calculated for each account and added to the account balance. Annual fees are charged to the credit account and deducted from the balance.
17
classes
Start by picking out the nouns in the specifications…

FIT9131 Week 9
Possible classes
metropolitan bank accounts
savings accounts check accounts credit accounts customers
money month interest balance annual fees
18

FIT9131 Week 9
Refining the list
metropolitan bank
accounts savings accounts check accounts credit accounts customers
money
month
interest
fees
discard the ones which are non-essential, too simplistic, duplicated, etc…
19
the rest will become candidates for classes in the design

FIT9131 Week 9
Final list
We could now design/implement these classes for the program :
accounts savings accounts check accounts credit accounts customers
20

FIT9131 Week 9
Identification of
Looking at the same specification again :
Metropolitan bank offers the following types of accounts to its customers: savings accounts, check accounts, and credit accounts. Customers may deposit money into an account or withdraw money from an account. At the end of each month interest is calculated for each account and added to the account balance. Annual fees are charged to the credit account and deducted from the balance.
behaviour
21

FIT9131 Week 9
Identification of
Example :
Metropolitan bank offers the following types of accounts to its customers: savings accounts, check accounts, and credit accounts. Customers may deposit money into an account or withdraw money from an account. At the end of each month interest is calculated for each account and added to the account balance. Annual fees are charged to the credit account and deducted from the balance.
22
behaviour
Start by picking out the verbs (actions) in the specifications…

FIT9131 Week 9
Possible behaviours
deposit withdraw calculated added charged deducted
these will become candidates for behaviour in the design
23

FIT9131 Week 9
Class Design
Equipped with a list of possible classes and behaviours for the program, we can then start designing our classes.
Various different design techniques are available.
24

FIT9131 Week 9
“CRC” Cards
CRC : Class, Responsibilities, Collaborators
It is a design technique for discovering classes, responsibilities and
collaborators :
• the emphasis is on the classes, what they do, and what other classes they work with
• uses small physical paper cards to describe the classes and their relationships
CRC cards are low-tech, inexpensive and can be used with individual/group of designers
(Beck & Cunningham, 1989)
25

FIT9131 Week 9
Example : A single
CRC Card
Class name
Responsibilities
(a high-level description of the purpose of the class)
Collaborators
(other classes used by this class)
(paper card)
Note : the physical size of the cards are deliberately kept small (typically 3”x5”, or 4”x6”), to reduce the complexity of the classes – principle of modularisation
26

FIT9131 Week 9
Example : a
Game Class (Assignment 1)
CRC Card
for the
Game
Responsibilities
• display menu
• accept user option • validate inputs
• set up new players • play one round
• etc….
Collaborators
• Player • Dice
• etc…
27
The programmer can then write the code using this card as a design template

FIT9131 Week 9
Another technique : ”
and Scenarios
Another analysis technique known as “use cases” can be used to obtain system requirements from users.
A use case is:
• a set of “scenarios” which together describe one system
goal, e.g. withdrawing money from an account • a snapshot of one aspect of your system
A set of use cases can then be used to describe the whole system.
Use cases represent an external view of the system. 28
Use Cases”

FIT9131 Week 9
A scenario example
Consider a Web-based online store:
The customer browses the catalogue and adds desired items to the shopping basket. When the customer wishes to pay, the customer describes the shipping and credit card information and confirms the sale. The system checks the authorisation on the credit card and confirms the sale both immediately and with a follow-up email. (UML Distilled, 1999)
What does this particular scenario really describe?
29

FIT9131 Week 9
More (expanded) scenarios
The customer browses the catalogue and adds desired items to the shopping basket. When the customer wishes to pay, the customer describes the shipping and credit card information and confirms the sale. The system checks the authorisation on the credit card and responds with a message that the credit card details are invalid. The user is requested to check the credit card details and re-enter them.
The customer browses the catalogue and adds desired items to the shopping basket. The customer then chooses to cancel the transaction.
This set of 2 scenarios (and possibly others relating to this task) will form one use case – which describes a customer order
30

FIT9131 Week 9
Some useful design guidelines
Postpone decisions:
• decisions that affect only a single component should be deferred
• interface design decisions are NOT important at this stage
Prepare for change:
• design carefully (increase modularity, reduce coupling, etc)
• consider hardware dependency (minimise)
• predict sources of change (eg. UI, I/O formats, etc) • document any design decisions!
31

FIT9131 Week 9
Another technique :
Responsibility
• Responsibility-Driven Design – an object-oriented design technique that is driven by an emphasis on object behaviour (Wirfs-Brock)
• Emphasizes the identification and independence of responsibilities within a collection of independent agents (Budd, 2002)
• Information hiding and modularity are key considerations.
32

driven design

FIT9131 Week 9
Starting with behaviour
Why consider behaviour first?
• When you design a program, what do you know first?
odata structures (for implementation)?
o programming constructs (if, while, etc)? o behaviour?
• Behaviour is (sort of) understood by both users and programmers. eg. A common first question is “what does this system DO”?
33

FIT9131 Week 9
Design example: Radio program planner
34
Suppose we are to design a “Program Planner” program for a small radio station. This planner is supposed to:
• hold a database of music titles
• make a program plan (list of music titles to
play) for each radio show for a day

FIT9131 Week 9
Program Planner actions
Design team (in initial discussions) identifies a few actions (behaviour) :
• browse database of existing titles
(for each title, the artist, the CD and the running time is shown)
• add new title
• edit or annotate existing title
• make a program plan for a day (each day has several shows, each show plays several titles)
• review existing program plan 35
Database management
Program management

FIT9131 Week 9
Example : a
class for the Program Planner
CRC
card for the
Welcome
Welcome
Responsibilities:
• display initial screen
• offer choice of program
options
• pass control to either
• musicdatabase manager
• program planner
Collaborators: •Database Manager
•Music Program Manager
36

FIT9131 Week 9
Example scenarios
• Radio station producer decides to schedule a special two hour “top hits show” each Sunday
• Requests the program manager to schedule new show
• Program manager requests the daily program organiser to make a new schedule for the Sunday programs
• Daily program organiser requests the show organiser to organise a two hour playlist of top hits
• Playlist organises a collection 37

FIT9131 Week 9
Program planner class design
note how the 3 classes highlighted in green here are “collaborating” with each other – as shown in the CRC card for the Welcome class
Welcome
Program Manager
Music Database Manager
PlayList
Daily Program Organiser
Song
38
Show organiser

FIT9131 Week 9
Design principles : Coupling and Cohesion
39
Cohesion: each component is a sensible unit that includes tasks that are related in some manner
• high cohesion is good!
Coupling: connections between components
• high coupling is bad!
A “component” can be a class, or a method.
More about these next week …

FIT9131 Week 9
Next Steps …
Refine descriptions of components Design general structure
• Decide how to implement components (class, methods …)
• Map responsibilities to methods, identify parameters
• Describe information held within each component
A component with only one behaviour and no internal state may be made into a method. Components with many tasks may be implemented as classes.
40

FIT9131 Week 9
Next Steps …
Design the representation
• decide which data structures to use • decide what algorithms to use
Implement components Integrate the components
• use dummies, stubs, gradually replace with working components
Test
• component, system, regression testing
Maintenance and Enhancement
41

FIT9131 Week 9
Design principle : Naming
Names of components are important!
• class names should be nouns in the singular
form (eg. Person)
• use capitalisation (eg. ProgramPlanner)
• avoid abbreviation and avoid ambiguity
(eg. “TermManager” – Terminal or Terminate?)
• method names should start with strong verbs (eg. withdrawMoney)
• avoid very generic names (e.g. Agent, Item, Process) – unless appropriate
42

FIT9131 Week 9
Review : Assignment 1 Issues
Some common mistakes in Assignment 1 : • Coding Standard violations
• bad names, poor formatting, lack of method comments, methods not in order, etc
• Design issues
• too many attributes, methods doing too many tasks,
scoping, etc • Coding issues
• code duplication, poor user interface, incomplete/wrong implementations, incorrect method usage, etc
• Poor code understanding
• Poor code modification skills
43

FIT9131 Week 9
Reminder : Assignment 2
• should have started working on it by now
• Important : do not try to write the code for the entire program at once! Develop the program in small stages, starting with the small class & small methods. Use stubs where necessary.
• show design/code to tutor every week for feedback • Important : discuss design with tutor
• attend helpdesk sessions as often as needed • start working on the Test Strategy document
• NB : you need to add simple validations to the mutators in order to perform negative testing
• practice code explanation/modification skills 44