1. Product Design Phases

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

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

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

5. Design Phase The design phase will consist of two parts –Product Design –Class Design

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

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

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

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

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

11. Internal vs. External Structure Example

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

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

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

15. 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…

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

17. 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)

18. 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?)

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

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

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

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

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

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

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

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

27. LMS Case Study: Relational Representation of Data Relational TablesBook Resource List Patron Address Patron

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

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

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

31. Why Cooperating Processes? Reuse Client/server application Process prioritization –Responsive to the user –Utilize idle time for background jobs …

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

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

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

35. 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”

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

37. Deployment Diagram Librarian Terminal Librarian Terminal Librarian Terminal Holdings DBMS workstation server key:

38. Deployment Diagram (cont.) Holdings DBMS Server Librarian Workstations

39. Sample Deployment Diagram Game Client Game Server Internet

40. Deployment Diagram (cont.) Flexibility is allowable because all we are trying to convey is the functional connectivity of the architecture –Intentionally lacking in detail

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

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

43. 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 trigger State with substates Transition with Event trigger

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

45. State Machines (cont.) Enter PasswordAuthenticate User characters typed typed valid user invalid user Login

46. Sample State Machine Showing Interprocess Communication Player Joining Game Get player name Select token { Client States} { Server State} Communicate remaining tokens player name available tokens selected token

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

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

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

50. Thread Notation Active Class -- single process with multiple threads Representation takes us back to the Class Diagram DBMS Server class Client GUI class GetsUserID() Active Class

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

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

53. User Interface (cont.) Application Functionality Internal Representations External Representations User Interface User

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

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

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

57. 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”…

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

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

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

61. UI Design Principles Know/understand your user Follow “tried and true” design rules

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

63. Know/understand your user (cont.) Gather information on the user –Age –Gender –Physical abilities –Education –Cultural or ethnic background –Training –Motivation –Goals –personality

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

65. “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

66. “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

67. “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

68. “Tried and True” design rules (cont.) Display only relevant information –Don’t make the user search for the answer –Context sensitive help

69. Interaction Styles Menu Selection Form Fillin Command Language Natural Languga Direct Manipulation

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

71. Design Summary Create solution for object persistence Develop user interface designs Determine process architecture