User:Hyad/SE/Test3

User Interface

http://www.se.rit.edu/~se361/slides/UIdesign.pdf

GUIs: “bones” vs. cosmetics

These are the “bells and whistles” that are added after the GUI foundation is in place (when appropriate).

• The basic experience is created by the underlying structure and concept of the information
  • Start with the basic “bones” before you add the frills.

Understanding the users

• Level of expertise using software in general
• Likely frequency of usage
• Capabilities and constraints e.g. young users, users using dialup

lines, using public terminals

Understanding the tasks

• What do they want to do with the software?
• What operations will they perform frequently?
  • Design to make most frequent tasks most convenient
• Do they already have ideas about how to do the operations?
• What variations are likely in the way they perform tasks?
• E.g. Two contrasting models, each useful for their context:
  • Applications such as MS-Word -perform hundreds of different tasks from the same screen
  • Wizards - perform exactly one task, with minor parameters and variations!

User Interface - the Foundation

• Need a consistent concept underlying the entire UI
• Using the model consistently throughout makes it easier for users to figure out how to perform tasks

User Interface - Navigation Plan

• Group related tasks together
  • Grouping levels: Screens, tabs, menus
• Have a consistent navigation scheme between screens
  • -->Match it to user workflow
• Be consistent in grouping and behavior

Usability

-->

• Ease of learning
  • Able to use software with little or no training
  • Use of software is faster the second time
• Productivity
  • Perform tasks quickly and efficiently
• Minimal error rates
  • Knowing whether operations worked, and if not, why it failed, and what can be done about it
  • If error occurs, provide good feedback so user can recover
• High user satisfaction
  • Users feel like they are driving – they issue the commands and software executes it, rather than it pulling them along and dictating to them - do they feel in control
  • Includes the ability to customize environment.

A Successful Product is one that is..

• Useful: accomplishes what is required (e.g. format a doc, play music)
• Usable
• Used: makes people want to use it, it is engaging, fun, etc.

---

Design Patterns

10/11/05 http://www.se.rit.edu/~se361/slides/DesignPatterns.pdf

Intro

• A pattern is the outline of a reusable solution to a general problem encountered in a particular context
• Many of them have been systematically documented for

all software developers to use A good pattern should

• Be as general as possible
• Contain a solution that has been proven to effectively solve the problem in the indicated context.
• Studying patterns is an effective way to learn from the

experience of others

• The seminal book on design patterns, "Design Patterns,

Elements of Reusable Object-Oriented Software" by Gamma et al, identifies three categories of design patterns

• Book is by: The Gang of Four

1. Creational
2. Structural
3. Behavioral

Pattern description

• Context: The general situation in which the pattern applies
• Problem: A short sentence or two raising the main difficulty.
• Forces: The issues or concerns to consider when solving the problem
• Solution: The recommended way to solve the problem in the given context. — ‘to balance the forces’ - (This is usually a diagram.)
• Antipatterns: (Optional) Solutions that are inferior or do not work in this context.
• Related patterns: (Optional) Patterns that are similar to this pattern.
• References: Who developed or inspired the pattern.
• Consequences - if you pick certain patterns - you can't do other patterns

The Singleton Pattern

• Context:
  • It is very common to find classes for which only one instance should exist (singleton)
• Problem:
  • How do you ensure that it is never possible to create more than one instance of a singleton class?
• Forces:
  • The use of a public constructor cannot guarantee that no more than one instance will be created.
    • Therefore, make constructor private.
  • The singleton instance must also be accessible to all classes that require it
    • Therefore, make a getInstance() method like:

if (theCompany==null)
 theCompany= new Company();
return theCompany;

• Cons
  • Don't work in threads
  • In O.O. programing, Singleton is treated just like other classes
  • Hard to clean up when not doing Java

• Summary = Best use for hardware - ex. COM ports

The Controller Façade Pattern

1. Creates a simplified interface to a complex system - for 99% of the time
2. But you should be able to tweak it and get into the dirty details that 1% of the time

ex. a program compiler

• Context:
  • Often, an application contains several complex packages.
  • A programmer working with such packages has to manipulate many

different classes

• Problem:
  • How do you simplify the view that programmers have of a complex package?
• Forces:
  • It is hard for a programmer to understand and use an entire subsystem
  • If several different application classes call methods of the complex package, then any modifications made to the package will necessitate a complete review of all these classes.

The Observer Pattern

• this most important pattern
• emphasizes decoupling
• ex. like making our UserDatabase interface and FileUserDatabase class. All the Entities access the UserDatabase interface, not the FileUserDatabase class.

• Context:
• When an association is created between two classes, the code for the classes becomes inseparable.
• If you want to reuse one class, then you also have to reuse the other.

--Now you don't

• Problem:
  • How do you reduce the interconnection between classes,

especially between classes that belong to different modules or subsystems?

• Forces:
  • You want to maximize the flexibility of the system to the greatest extent possible
  • You can make Observer class inherit from the Obserable interface in Java

Bad: the problem with the Java is that you cannot inherit from Observable if you want to inherit from something else too. In Java, you can't have multiple inheritance. Also, put notifyObserver() calls in their own thread.

• Antipatterns (the wrong way to do problem):
  • Connect an observer directly to an observable so that they both have references to each other.
    • Observers “poll” observables for changes
    • Observerables “call” update methods directly
  • Make the observers subclasses of the observable.

---

Dynamic Modeling

10/13/05 http://www.se.rit.edu/~se361/slides/DynamicModeling.pdf

• Used to model the dynamic aspects of a software system
  • Interaction Diagrams - Interactions between objects
  • State Diagrams - Object state

Interaction Diagrams

• Instances of classes - Shown as boxes with the class and object identifier underline
• Messages - Shown as arrows from actor to object, or from object to object

There are two kinds of interaction diagrams:

• Sequence diagrams
• Collaboration diagrams

Sequence diagrams

• shows prodecure in timeline: going down diagram = further in time
• ex. my CS4 Proj. 1-1 readme
• focused on sequence
• you can see each layer's behaviors
• If an object’s life ends, this is shown with an X at the end of the lifeline

Collaboration diagrams

- show the same information Sequence diagrams show except it's arranged differently

• ordering is represented by numbers (1.,2.,3.,...)
• focused on sturcture

• Collaboration diagrams emphasise how the objects

collaborate in order to realize an interaction

• • A collaboration diagram is a graph with the objects as the vertices.
  • Communication links are added between objects
  • Messages are attached to these links.
  • Shown as arrows labelled with the message name
  • Time ordering is indicated by prefixing the message with some numbering scheme.

State Diagrams

• focused on states
• good for GUI design, or website
• easy to understand, but hard to make
• ex. tic-tac-toe game diagram on PDF - slide 11 of 22
• don't represent if statements very well

A state diagram describes the behaviour of a system, some part of a system, or an individual object.

• At any given point in time, the system or object is in a certain state.
• Being in a state means that it is will behave in a specific way in response to any events that occur.
• Some events will cause the system to change state.
• In the new state, the system will behave in a different way to events.
• A state diagram is a directed graph where the nodes are states and the arcs are transitions.

State

At any given point in time, the system is in one state.

• • It will remain in this state until an event occurs that causes it to change state.
  • A state is represented by a rounded rectangle containing the name of the state.
• Special states:
  • A black circle represents the start state.
  • A circle with a ring around it represents an end state.

Transitions

• A transition represents a change of state in response to an event.
  • It is considered to occur instantaneously.
  • The label on each transition is the event that causes the change of state.
• ex. - think stop light - also in PDF

State Diagram w/ Transitions -NOT representation of classes!

if red light override

     r.l.o.                       r.l.o 50 sec.
     ------>                        -------->
green ---(showYellow)---> yellow ---(showRed)--> red
 ^           60 sec.                10 sec.     |
 |(showGreen)                                   v
  <----------------------------------------------