product design phases. design structured walk-through marks the end of the analysis phase and the...

Product Design Phases

Design

• Structured Walk-Through marks the end of the Analysis phase and the beginning of the Design phase– Recall the Structure Walk-Through is given

by the design team to a general audience– Objective is to present the developer’s

view of the system and to gain confirmation of their understanding/proposed approach from the audience

Recap of UML (so far)

• Use Case Diagrams– Give a high level pictorial view of the

system functionality

• Class Diagrams– Give a static view of system objects and

their relationships

Analysis -> Design

• Goals of analysis – Understand the functional requirements– Represent the functional requirements in an

unambiguous notation that will support design

• Goals of design– Represent/model the system– Models should support implementation

• UML/UCCD supports these goals– Provides a seamless progression between

development phases

Design Phase

• The design phase will consist of two parts– Product Design– Class Design

Product Design versus Class Design

• Product design concerns itself with creating effective interactions– Between the system and human users– Between distributed elements of the system– Between software system and solutions for data

persistence (e.g. database management systems)

• Class design concerns itself with determining class definitions:– Attributes– Method signatures– Class semantics

Product Design

• Primary goal of Product Design is to create effective interactions– Between processes that make up the

system– Between systems that work together to

solve the problem– Between the system and its users

Product Design (cont.)

• Process architecture design– The big picture

• Interprocess communication– How the processes within the big picture

communicate with one another

• User interface– How users will communicate with the big

picture

External Structure

• Software components that interact with external resources

• Database• Files• Networks • Devices• Users

• Everything else is internal structure and will be addressed during class design

Internal vs. External Structure• In our simple drawing program example

– External structure• Output device (monitor, printer)• Input device (mouse, tablet, touch-screen)• File system (for loading/storing pictures)

– Internal structure• Circles, squares, triangles• Operations on shapes

Internal vs. External Structure• Example

Product Design Objectives• Data Persistence

– Saving system state– Accessing external data sources

• Process Architecture– Distributed/coordinated computation and

resource use

• User Interface– How the user interacts with the system

Product Design Issues

• Data Persistence– Saving system state– Accessing external data sources


resource use


Data Persistence

• Scenarios for data persistence– User uses the system, stops the system,

then starts it up again– System requires access to large amounts

of data that cannot be completely held in memory

– System requires simultaneous access to data objects

– Fail-safe operation

Data Persistence (cont.)Three items of particular interest:

1) Objects (state of an object) that must be stored on permanent, long-term, large memory (e.g. disk) devices

2) The “state” of the system should be saved at the end of each use

3) The previous “state” of the system should be restored at the start of every run– Open files, pointers within files, preferences…

How To Implement Data Persistence?• Database Management System?

– Addresses first item but typically difficult to use within an object oriented designed system

– Most database products are relational• Store many similar item• Primarily used for queries• Must provide a translation for use with objects

– Overkill for other two issues

Serialization

• A better approach to 2 and 3• Not suitable for large relational DBMS access• Better suited to [relatively] small amounts of

object-oriented data• Literally stream the components from their

ADT (object) form into individual bytes• Store the bytes to disk in a serial (sequential

fashion)

Serialization (cont.)

• Add-on to the C++ language (Microsoft Foundation Classes)

• Built in to the Java language– Saves the object type– Writes base/derived class data in

“appropriate” order– Writes everything efficiently (how do we

verify this?)

Serialization (cont.)

• Built in to the Java language (cont.)– Keeps track of aggregate references– Avoids circular references– Allocates object memory of proper size/type on

read back

• Basically, it saves the programmer a lot of work

• If your language doesn’t support it, you’ll have to do it yourself

Translation

• If you must translate between a relational DBMS structure and an object-oriented structure…– You have work to do– These will be implementation specific details– You’ll likely create “translation” classes or

interfaces or maybe just functions– We won’t go into this here

Back to Persistence

• Items to be considered with designing data persistence into a system– Security

• Restrict access to stored data• Validate data on read• Serialization usually creates binary (non-human

readable) files

Why Binary?

• Less likely to have a user tamper with the file thus introducing errors or inconsistencies in the system

• A crude form of security

Evaluating Object Persistence• Security

– Hacker proof– Allows reconstruction in face of malicious use

• Information growth– Solution still works with increased data volume

• Concurrency– Concurrency solution allows for increased users

Back to Persistence (cont.)• Items to be considered when designing

data persistence into a system (cont.)– Data Growth

• If the amount of data in the system grows, can the persistence process handle it?

• Plan for evolutionary development

Back to Persistence (cont.)• Items to be considered when designing

data persistence into a system (cont.)– User Growth

• If the number of users of the system grows, can the persistence process handle it?

• Especially important if there are concurrent users

• Plan for evolutionary development

LMS Case Study: Object Persistence

• LMS may contain hundreds of thousands of book entries as well as thousands of other library resources

• such a volume of data does not permit object streaming

• A DBMS is called for to provide– Concurrent access by multiple users– Security enforcement of different access levels for

various user categories– Allow for increased data capacity

LMS Case Study: Relational Representation of Data

Relational TablesBook

Resource List

Patron Address

Patron




resource use


Process Architecture

• Software systems may consistent of processes interacting over a network

• Process architecture lays out the machines (nodes) that will host the processes making up the system

• Process architecture determines the behavior of the distributed processes

• Deployment diagrams are used to model distributed processes

Process Architecture (cont.)• The system may consist of a set of cooperating

processes that execute on one or more machines– The machines are called nodes– The processes are either threads or processes

• Functions must be mapped (assigned) to processes• Processes must be mapped (assigned) to nodes

– Why break a system into cooperating processes?• This mapping is referred to as modeling

Why Cooperating Processes?

• Reuse

• Client/server application

• Process prioritization– Responsive to the user– Utilize idle time for background jobs

• …

Cooperating Processes

• Processes• Multiple, concurrent

operations in separate executable entities

• Communication is through message passing or special memory designated by the operating system

• Threads• Multiple, concurrent

operations within a single executable entity

• Communicate through message passing or shared memory designated by the program

• Processes and threads are both techniques used to achieve concurrency

Cooperating Processes (cont.)• Implementation of processes and

threads are a language-specific, library-specific, or operating-system specific detail– Java supports threads– C++ supports threads through operating

system or library extensions

What is Modeling?

• Specify the functionality of each process• Specify the communication requirements

between processes• Specify the nodes on which the processes

will execute• The last two may help to define whether the

processes are threads or processes– Threads – must run on the same machine– Processes – may run on separate machines

Modeling (cont.)

• Goals of Modeling– Partitioning (mapping) for efficiency in the

software engineering process• It’s easier to visualize the system this way

– Partitioning (mapping) for efficiency in the runtime environment

• The system runs “better” this way

– These goals may contradict one another– More of an “art” than a “science”

Modeling and UML

• Processes are represented by Deployment Diagrams

• Threads are represented by Active Class Constructs

• But, the notation is somewhat flexible– The designer is given the freedom to

define the notation that best suites the given need

Deployment Diagram

LibrarianTerminal

LibrarianTerminal

LibrarianTerminal

HoldingsDBMS

workstation

server

key:

Deployment Diagram (cont.)

Holdings DBMSServer

Librarian Workstations

Sample Deployment Diagram

GameClient

GameClient

GameClient

GameServerInternet

Deployment Diagram (cont.)• Flexibility is allowable because all we

are trying to convey is the functional connectivity of the architecture– Intentionally lacking in detail

Interprocess Communication• State Machines are the UML method

for specifying the detail– This is a relatively simple method for

specifying a potentially complex deployment diagram

Modeling Interprocess Communication• Deployment diagrams show the distribution of

process over multiple nodes but do not indicate how these processes communicate

• State machines may be used to model communication between processes

• The idea behind using state machines for modeling inter process communication is that the system enters a new state when messages are exchanged between processes

State Machines

• A universally accepted method for modeling and implementing process behavior

• Simple set of notational elements

state-name

Initial state

Intermediate state

Final state

triggerState with substates

Transition withEvent trigger

State Machines (cont.)

• Processing begins at initial state• Proceeds to intermediate states

– Event triggered transition• Leave one state, enter the next

– Unconditional transition• Processing in the state finishes (e.g. start state)

– Concludes when the (a) final state is reached

• May be more than 1 final states


Enter Password Authenticate User

characters typed <cr> typed

valid userinvalid user

Login

Sample State Machine Showing Interprocess Communication

Player Joining Game

Get player name

Select token

{ Client States}

{ Server State}

Communicate remaining tokensplayer name

available tokens

selected token


• Like everything else, state machines will be developed through a series of refinements

• The process ends when all states are “self-explanatory”

• The process results in a hierarchy of state machines

• Root node of the hierarchy is the system itself


• Note that these are NOT flow charts!!!– Flow charts provide a one-to-one

correspondence with code– State machines provide a one-to-one

correspondence with architectural elements

Processes/Threads and State Machines• State Machines designate communications between

functional blocks– Note that you may have multiple state machines that reside

on different platforms– The trigger events for one state machine may come from

another (see page 126 of the text)

• They should provide some indication as to a “reasonable” partitioning/mapping into processes/threads

• States can be specified as residing in a particular process (no particular notation)

• Threads have their own notation

Thread Notation

• Active Class -- single process with multiple threads

• Representation takes us back to the Class Diagram

DBMS Server class Client GUI classGetsUserID()

Active Class




resource use


User Interface

• The UI is the “Language” in which– User tells system what to do– System tells user what to do (or what it did)– System functionality – semantic– User manipulations – syntactic– Translator between the internals and

externals of the system

User Interface (cont.)

Application Functionality

Internal Representations

External Representations

User Interface

User

User Interface (cont.)

• But, more important than all that, the UI consists of interaction techniques– Well, more important to the customer/user

at least– The translation is probably foremost on the

minds of the designers

Interaction Techniques

• Input devices used to get information into and out of the system (from/to the user)

• This should be considered a separate issue from the actual functionality

• The application should not be dependent on the UI and vice-versa

• Want the flexibility to change the UI without changing the application

Information Content vs. Information Form• Content – application functionality

– What does the data represent– How is it stored

• Form – presentation of the data – How will the user input the data– How will the system output the data

Human-Computer Interaction• In recent years this has become an

independent field of study– University courses– International conferences– Technical journals– Books

• AKA “Ergonomics”, “Accessibility”, “Friendliness”…

Human-Computer Interaction (cont.)• Five generally accepted design factors

1. Ease of learning

2. Speed of use

3. Frequency of user errors

4. User satisfaction

5. Knowledge retention

• I would add, “special needs” to the list

Human-Computer Interaction (cont.)• The factors may be “mutually exclusive”

– Consider emacs or vi (for you UNIX people) vs. NotePad

– Consider command-line UNIX (or DOS) vs. Windows

– In both cases, the command line can be much faster but is far more difficult to learn

• Bottom line – user satisfaction

User-Friendliness

• Easy to learn/remember instructions• Context sensitive help

– Maybe even tie this to your state machine

• Logical grouping of functionality– e.g. file functions under same menu item

• Graphical when possible• Easy activation of functions

– e.g. “hot-keys” for popular menu items

UI Design Principles

• Know/understand your user

• Follow “tried and true” design rules

Know/understand your user• Three broad user categories (profiles)

– Novice user• Provide clear, concise instructions (hold their

hand)• Minimize possibility of error (keep it simple)

– Knowledgeable, intermittent user• “tool tips” (hints/reminders)• Ability to “explore” without hurting anything

– Frequent user• Short cuts

Know/understand your user (cont.)• Gather information on the user

– Age– Gender– Physical abilities– Education– Cultural or ethnic background– Training– Motivation– Goals– personality

Know/understand your user (cont.)• Potential users can be tested or surveyed for

skill levels• Most systems will need to address the entire

spectrum of capabilities• In general, the software engineer is NOT the

best person to gather this information– I’ve seen it attempted before…it’s not

pretty– Hire an ergonomic specialist

“Tried and True” design rules• Be consistent

– Especially applies to terminology

• Provide short-cuts– These will keep your frequent users happy and not

overburden your novice users

• Offer useful, meaningful feedback– Audio, visual, or other sensory feedback– Video game controllers now have “rumble”

feedback

“Tried and True” design rules (cont.)• Offer a beginning and ending of each

user input sequence (rest is the middle)– e.g. “submit” button

• Prevent catastrophic mistakes– Don’t allow invalid inputs (e.g. stop the

problem before it starts)

• Verify deletion tasks– It’s just a nice thing to do

“Tried and True” design rules (cont.)• Allow for reversal of actions

– “undo” command

• User should be thinking about the task, not the interface– Strive for a transparent interface

• Do not rely on a user’s memory– Duplicate information if applicable– Context sensitive help is useful here– Tool tips are also very useful

“Tried and True” design rules (cont.)• Display only relevant information

– Don’t make the user search for the answer– Context sensitive help

Interaction Styles

• Menu Selection

• Form Fillin

• Command Language

• Natural Languga

• Direct Manipulation

Few UI Tools

• This is the stuff that “Visual Programming” is made of– Visual Programming(C++, Java...)– Visual Basic

Design Summary

• Create solution for object persistence

• Develop user interface designs

• Determine process architecture

product design phases. design structured walk-through marks the end of the analysis phase and the...

Documents