Date post: | 28-Dec-2015 |
Category: |
Documents |
Upload: | holly-heath |
View: | 213 times |
Download: | 0 times |
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
• Process Architecture– Distributed/coordinated computation and
resource use
• User Interface– How the user interacts with the system
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
Product Design Issues
• 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
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
State Machines (cont.)
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
State Machines (cont.)
• 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
State Machines (cont.)
• 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
Product Design Issues
• 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
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