Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

ITECH3501/6501 W03

No description
by

Jackie Rong

on 8 August 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of ITECH3501/6501 W03

Week 3: System Design
S
ftware Engineering
Principle
of
ITECH3501/6501
Jia Rong, jiarong@acm.org
What have we covered last week?
Requirement Definition
Requirements deficiencies are the prime source of project failures.
Law 1 -
(Robert Glass 1998)
Software requirements express the needs and constraints placed on a software product that contribute to the solution of some real-world problem.
(Kotonya and Sommerville, 2000)
Errors are most frequent during the requirements and design activities and are the more expensive the later they are removed.
Law 2 -
(Boehm 1975)
Prototyping reduces requirements and design errors, especially for user interfaces.
Law 3 -
(Boehm 1984)
The value of the model depends on the view taken, but none is the best for all purpose.
Law 4 -
(Davis 1990)
Objective models reduce communication problems between analysts and users.
Hypothesis 1 -
(Booch 1991)
Today, we have a look at

System Design
What is
good

design
?
What is
good design process
?
Why
system design is so
important?

What
do we
do
to design a system
?
Design generates a proposed technical solution, which meets the system requirement.
We simulate what we want to make or do
We iterate till the design is adequate
We prepare a technical plan, which tells other people how to construct the system
We write a design specification
System Design answers the questions:
Which functions will be implemented?
How will these functions be invoked by users?
How will the system be structured?
How should each function be implemented?
Time
Cost
Performance
Note
Take account of time, cost and performance constraints

A full design only for large or complex system
System Design is an artifact
limited by the ability and foresight of who makes it and the circumstances of its creation

design is the most challenging and most creative activity in software engineering

knowledge of the user requirements translates into knowledge about the computer system

good design is a good match
Properties & Process
What are good design? For what reason?
How to perform task?
End up as the design specification
Easy
Difficult
Whether system functions and user community are clearly defined?

Has any conflicts among the developers or user groups?
Network and Hardware Structure
Human
Interface
Storage and Retrieval
Processing Programs
System Design Process
Note
There is no single best design for all systems.

It is better to spend more time on design than to start coding.

The key problem in design is that it requires knowledge of both applications and computation.
Law 5 -
Good designs require deep application knowledge.
(Curtis 1990)
Hierarchical Structures
Sub-system
(Process)
Entire System
Subsub-system
(Process)
Subsub-system
(Process)
Subsub-system
(Process)
Sub-system
(Process)
Subsub-system
(Process)
Sub-system
(Process)
Sub-system
(Process)
Sub-system
(Process)
Subsub-system
(Process)
Law 6 -
Hierarchical structures reduce complexity.
(Simon 1962)
Law 7 -
A structure is stable if cohesion is strong and coupling is low.
(Constantine 1974)
intra-module communication
inter-module interaction
the vulnerability of the structure to the normal incidents of programming

modifications required by design or environment changes
Law 8 -
Only what is hidden can be changed without risk.
(Parnas 1962)
Law 9 -
Separation of concerns leads to standard architectures.
(Denert 1991)
Law 10 -
Screen pointing time is a function of distance and width.
(Simon 1962)
Hypothesis 2 -
Object-oriented designs reduce errors and encourage re-use.
(Booch 1991)
Hypothesis 3 -
Formal methods significantly reduce design errors, or eliminate them early.
(Bauer-Zemanek 1982)
Hypothesis 4 -
Reusing designs through patterns yields faster and better maintenance.
(Gamma 1995)
Graphical User Interface
The golden rules of interface design:
strive for consistency
enable frequent users to use shortcuts
offer informative feedback
design dialogs to yield closure
offer error prevention and simple error handling
permit easy reversal of actions
support internal locus of control
reduce short-term memory load
The information hiding or encapsulation principle led to the development of abstract data types, the basis of object-oriented design.

Modules should be divided so that each is changeable without impact on others.
Each module should be concerned with only one thing at a time.
Use Cases and classes identified during requirements are directly translatable into design.
Make use of concepts like sets and relations to generate and document a design result in a higher degree of reliability as they remove ambiguity and imprecision
Experienced designers reuse successful elements of previous design
Programmer productivity and program quality are improved
Skills of novices are increased by reusing proven concepts
Communication among designers is easier
Encourages the exchange of good design idea
Maintainability of programs is improved
How can we evaluate the quality of the system design?
Depends on how well the design meets the requirements

Is the design easy to build the system?

An awful and useless product may be well designed, and vice verse

Detailed enough that the planning and cost estimating for the next phase can be done

Evaluate which information needed by whom, and when
Full transcript