sample use case templateexample test plan templateProject plan template
ICS 121: Design Qualities and Concerns
- Synthesis and Analysis
- Design in the overall process
- Design qualities
- Types of design
- Software architecture
- Object-oriented design
- User interface design
- Database design
- Design principles
Synthesis and Analysis
- Synthesis: the combination of things to build a larger whole
- Analysis: the examination of things to understand their important aspects
- Usually people think of design as just synthesis. Some would
even say that design is a creative process that is hampered by
critical analysis too early.
- As an engineering activity, software design must be
goal-oriented and measured against those goals at every step.
- Common types of synthesis in design:
- Selection of elements from a library to add to your system
- Invention of new elements
- Composition of elements in your system
- Choice of parameters of elements
- Common types of analysis in design:
- Heuristic review by experts
- Comparison to past experience
- Design checklists
- Formal theoretical review
- Empirical analysis (actual measurements)
The role of design in the overall process
- V-shaped waterfall
- Design bridges requirements and implementation:
- Reacts to requirements, satisfies each of them
- Guides implementation
- Guides integration testing
- Understanding the design is key to team participation
- The design is an overview of the implementation
- The design highlights difficult or unexpected aspects
- The design indicates supported methods of extension/evolution
Some Product Qualities that are Largely Determined in Design
- Feasibility: could it be built? would it work?
- Correctness: does it actually produce the right results?
- Understandability: can the development team understand it?
- Testability: can it easily be tested with the tools you have?
- Scalability: could it handle enough users/data?
- Performance: would it work fast enough?
- Safety/Security: are safeguards in place?
- Extensibility: could we add more functionality later?
- Flexibility/Maintainability: could we change the implementation easily?
- Usability: can people easily learn and use it?
- In short, every product quality depends on design
- What are the major components of the system?
- Where/how are those components deployed?
- How will those components communicate?
- Is the design scalable?
- Is the design extensible? Easily?
- Homomorphic design: basically start with a domain model, then
make implementation objects match to domain object
- Define objects, attributes, relationships, inheritance,
- Design patterns: learn and use common patterns of design to
solve recurring problems.
- Is the design understandable?
- Is the design extensible? Easily?
- Is complexity managed?
User interface design
- The best advice for non-expert UI designers is to mimic other successful UIs.
- Start with a deep understanding of users' tasks. Then build
the UI to support those tasks, in priority order.
- Try to avoid inventing new metaphors, widgets, or interaction
techniques. Use existing widgets in accordance with standard guidelines.
- Check for conformance to guidelines.
- Cognitive walk-throughs
- Use mockups to test use cases and prompt feedback
- Consider feedback from users very seriously, but do not
attempt an empirical user study unless you know how to do it.
- Identify objects and attributes as is done in OO design
- Identify/define primary keys and foreign keys
- Address data redundancy and update issue via normalization
- Specify validity constraints in the schema when they _always_ hold
- Check against requirements, push every boundary case
- Check normalization rules, goal is usually 3rd normal form
- Test with actual data
Design Principle: Abstraction
- Abstraction is representing many specific possibilities with
one generic representation.
- There can be a range of representations from concrete to
abstract. For example:
- Too concrete: Jason Robbins teaches ics121
- Still too concrete: A lecturer, L, teaches a course, C.
- About right: An instructor, I, teaches a course, C.
Instructors may be professors or lecturers.
- Too abstract: A person, P, leads an activity, A.
- During design, a designer decides which details to include in
the design and which details to drop. Also, some details may be
represented more generically than others.
- The word "abstract" may be used as a verb, meaning to change a
design decision to make it more abstract. E.g., "we started off
with the assumption that all courses were taught by lecturers, but
then we abstracted that relationship to allow any type of
- An "abstraction layer" is a set of classes or other design
elements that allow the system to work with more generic
representations. See example below.
Design Principle: Separation of concerns
- Consider each aspect of the system separately. Design the
system so that each aspect can change independently of other
- Some common concerns in design:
- User interface structure, look and feel
- Business rules: how the system makes key decisions
- Data storage formats
- Security: limiting access to only authorized users
- Internationalization and locales: human language used for input and
output, timezones, currencies, and date and time formats
- E.g., "we started off with the assumption that TELE would keep
all data in a single relational database, but then we decided to
add an abstraction layer so that data could be in a UCI database or
a UC-system database. The rules about enrollment do not have to
change, because they do not deal with the databases directly: only
the abstraction layer deals with the databases."
- E.g., "In v1.0 we only handled US Dollars, but now in v2.0, we
introduced a Money class that can handle USD or Euros and convert
between them as needed. That way, the rest of the code does not
need to make assumptions about currency, it just treats everything
as instances of class Money."
Design Principle: Information hiding
- A class should show as little information about itself as
possible. For example:
- Make only certain operations public
- Make all attributes private
- Make all auxiliary operations private or protected/li>
- The goal of information hiding is to discourage other classes
from making too many direct references to this class. That way you
make changes to your implementation without having to change other
- Good information hiding defines a clear "API" for each class.
Other developers looking at your class should only need to
understand the API, not the internals of your class.
Design Principle: Low coupling, high cohesion
- Coupling is the references between classes:
- High coupling: every class makes many references to other classes.
Hard to change one class without changing other classes. Bad.
- Low coupling: each class makes only a few references to
others when needed. You can make most system changes by editing only
one class at a time. Good.
- Cohesion is the logical unity of a single class
- High cohesion: all the attributes and operations of a class
work together to represent one part of the system. Each part of
the system is in its own class or module. Good.
- Low cohesion: one class does two or more unrelated
things. That class or module is a "junk drawer" with a lot of
stuff there, but it is hard to find the thing you need.