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: 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)

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

Synthesis
- What are the major components of the system?
- Where/how are those components deployed?
- How will those components communicate?
Analysis
- Is the design scalable?
- Is the design extensible? Easily?

Synthesis
- Homomorphic design: basically start with a domain model, then make implementation objects match to domain object
- Define objects, attributes, relationships, inheritance, behavior
- Design patterns: learn and use common patterns of design to solve recurring problems.
Analysis
- Is the design understandable?
- Is the design extensible? Easily?
- Is complexity managed?

Synthesis
- 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.
Analysis
- 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.

Synthesis
- 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
Analysis
- Check against requirements, push every boundary case
- Check normalization rules, goal is usually 3rd normal form
- Test with actual data

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 instructor."
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.

Consider each aspect of the system separately. Design the system so that each aspect can change independently of other aspects.
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."

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 classes.
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.

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.