University of Southern California Center for Systems and Software Engineering CS577a: Understanding the SSAD, Use-Cases and GUI Prototyping David Klappholz, Nupul Kukreja 10/7/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Agenda Understanding the SSAD and what goes where Review of System Context and the Artifact & Information Diagrams An overview about a more precise way of writing the English text Use cases” – by looking at some of the use cases for the Internet Bookstore system GUI Prototyping – what/how/why? 10/7/ © USC-CSSE

University of Southern California Center for Systems and Software Engineering System and Software Architecture Description (SSAD) From the IICM-EPG:  The purpose of the SSAD is to document the results of the object-oriented analysis and design (OOA&D) of the system being developed.  The SSAD is used by the builder (programmer) as reference to the system architecture. The system being developed should be faithful to the architecture specified in the SSAD.  Futhermore, the SSAD is used by the maintainer and clients to help understand the structure of the system once the proposed system is delivered 10/7/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering SSAD – Layout 1.Introduction 2.System Analysis  System Analysis Overview  System Context  Artifacts & Information  Behavior  Capability ‘X’  Process ‘Y’  Modes of Operation  System Analysis Rationale 10/7/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering SSAD – Layout (cont’d) 3.Technology Independent Model  Design Overview  System Structure  Design Classes  Process Realization  Design Rationale 4.Technology Specific System Design  (Same subsections as Section 3) 5.Architectural Styles, Patterns and Frameworks 10/7/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering SSAD – Sectional Overview 10/7/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering System Analysis The ‘System Analysis Overview’ subsection highlights the ‘high level’ analysis model of the system to be developed It contains three important models –System Context Diagram –Artifacts and Information Diagram –System Behavior (i.e., Use-Case Model and Descriptions) We cover all of these in today’s lecture 10/7/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering System Context In the previous lecture on ‘Architecture’ we mentioned that every architectural element has an execution context – i.e., it’s dependencies on ‘other’ components, the execution environment, files etc., Similarly there exists a context for the System’s Execution as a whole: the system to be developed also has various dependencies – either on other systems, the physical entities interacting with it etc., It’s extremely important to capture this information to ensure that the corresponding ‘interfaces’ for communication have been designed for in the architecture Failure to capture this ‘context’ is a successful recipe for failure! 10/7/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering 10/7/2009© USC-CSSE System Context Diagram (SCD) – A ‘black-box’ view of the system

University of Southern California Center for Systems and Software Engineering SCD - Notes On the previous slide we saw the SCD for the Internet Bookstore System that we’ve spoken about in the previous lectures All external ‘entities’ whether other systems or humans are represented as ‘Actors’ as per the UML notation The multiplicities and the ‘association names’ are made explicit for better understanding They help better scope the project before committing for full up development right away. 10/7/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Artifact and Information Diagram Captures the ‘Persistent Data’ that the to-be-built system needs to maintain Captured by the means of ‘Class Diagrams’ and can also be referred to as a ‘Persistent Data Class Diagram’ The ‘first-cut’ diagram need not have ‘attributes and/or methods’ per se, but they need to be identified as one gains more information These ‘classes’ are then mapped to RDBMS tables (can also be to flat files and other storage mechanisms) Must be ‘normalized’ to at least 3NF (3 rd Normal Form) for storage – easier with class diagrams We see an example on the following slide – with some nuances… 10/7/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Artifact and Information Diagram: Internet Bookstore (subset) 10/7/2009© USC-CSSE *

University of Southern California Center for Systems and Software Engineering Artifacts & Information – Fine Print Key points to note: –We showed only a very small subset of the persistent data that they system needs to maintain –The Master Book Catalog (MBC) ONLY has methods and NO ‘internal’ data of its own – it relies on data from the ‘Book’ class; The requirement for this MBC class as a persistent class is ‘questionable’ and needs to be reviewed –The Customer class has an explicit association to an Address class rather than have ‘address’ as an attribute – this is an example of ‘class normalization’ where complex attributes are separated out into their own class –The Account class is shown to have 2 subclasses – they could have just been modeled as an ‘Account Type’ attribute that can take either of the 2 subclass names as input values – needs to be reviewed. 10/7/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Artifacts & Information – Extremely Fine Print There exists an “Object-Relational” mismatch that must be addressed Examples: –Many-to-many relations require a ‘mapping’ table in an RDBMS, whereas this is inherently a part of the Object Oriented representation –The inheritance facility in the OO approach may not exist in the underlying RDBMS and must be managed accordingly (i.e., attribute based, table inheritance etc.,) –Must deal with Data Normalization vs. Class Normalization (subtly different) –Foreign/Primary keys required for DB storage are NOT explicitly captured in the OO Class Diagrams 10/7/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Addressing the Object-Relational Mismatch There MUST be appropriate provisions for providing mappings between the ‘Object Schema’ and the corresponding ‘DB Schema’ OR Have the underlying DB schema be of the form’ ONE table per persistent class of the Object Schema’ –Advantage: Underlying ‘structure’ of the data is similar to what the application expects –Disadvantage: You could land up with lot of redundant data and Data Modelers could give you a tough time! DO NOT underestimate the importance of Object Persistence. 10/7/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Use-Cases Captured in the “Behavior” section of the System Analysis in the SSAD The model is captured using RSM along with a textual description for each of the ‘use- cases’ (a.k.a Capabilities) The Use-case ‘Process’ is captured in a tabular format – both the basic and alternate courses of action are captured (Note: All of the above is elaborated later in the lecture) 10/7/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Modes of Operation Most systems developed as a part of 577 projects do not have multiple ‘modes of operation’ ‘Modes of Operations’ is there to explicitly state if multiple such modes exist eg.: –If a system explicitly operates in ‘user’ mode and ‘administrative’ mode it would offer access to different (or extra) functionalities of the system –A text editor like ‘Vi’ on Linux/Unix operates in ‘text’ mode and ‘command mode’ –The Windows OS offers a ‘safe mode’ that only provides a subset of system functionality 10/7/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Technology Independent/Specific Model It contains the following: System Structure –Hardware Component (Class) Diagram –Software Component (Class) Diagram –Deployment Diagram We see examples of each on the following slides 10/7/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Hardware Component Diagram 10/7/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Software Component Diagram 10/7/2009© USC-CSSE A package/component view of the various identified ‘components’ of the system

University of Southern California Center for Systems and Software Engineering Deployment Diagram 10/7/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Hardware Component Diagram (HCD) Vs. Deployment Diagram The HCD shows what all hardware ‘component’ are required for the application and how are they connected to each other (i.e. Nodes in RSM) A deployment view contains ‘instances’ of the various hardware components shown in the HCD (i.e., Node Instances in RSM) Ex.: –‘Web Server Machine’ – is some machine that the server executes on (if known in advance, you could also say for example, ‘Sun Blade Machine’) –‘WinXP:Web Server Machine’ is an instance of the ‘Web Server Machine’ on which various components are deployed 10/7/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Technology Independent/Specific Model - II System Structure also contains two very important models: –Design Classes –Process Realization (Sequence Diagrams) In the subsequent lectures on OOA&D we would be focusing on these aspects explicitly We would look at the progression from the Domain Classes  Analysis Classes  Design Classes that would then be documented in the SSAD & the corresponding sequence diagrams 10/7/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Architectural Styles, Patterns and Frameworks Here you state the choice of the architectural style and the rationale for that choice You also highlight which external frameworks would be used to develop the system. For example, Struts, Hibernate,.NET etc., As mentioned in the lecture on Architecture, the difference between ‘Styles and Patterns’ is very subtle and will not be distinguished in 577 and we will use the terms interchangably. 10/7/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Use Case Elaboration 10/7/2009© USC-CSSE Based on the Internet Bookstore System covered in the previous OOA&D lectures

University of Southern California Center for Systems and Software Engineering Points to Note We assume that the ‘System Requirements’ have been captured – they need not be finalized, but must have a relative level of confidence on their accuracy (for the Internet Bookstore example we assume that the ‘Desired Functionalities’ outlined earlier have been transformed/finalized into Requirements for the system – shown on the following slide) The use-case elaborations presented are at a low level of granularity – i.e., they talk about the ‘buttons’ or ‘links’ the user must click etc., Arriving at this level of granularity is “Iterative” – the initial level of use-cases may be very coarse grained and not have ANY reference to GUI elements whatsoever 10/7/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering The bookstore shall accept orders over the internet The bookstore shall maintain a list of accounts for up to 1,000,000 customers The bookstore shall provide password protection for all accounts The bookstore shall provide the ability to search the master book catalog The bookstore shall provide a number of search methods on that catalog, including search by author, search by title, search by ISBN number, and search by keyword The bookstore shall provide a secure means of allowing customers to pay by credit card The bookstore shall provide a secure means of allowing customers to pay via purchase order The bookstore shall provide a special kind of account that is pre-authorized to pay via purchase order The bookstore shall provide electronic links between the Web and database and the shipping fulfilment center The bookstore shall provide electronic links between the Web and database and the inventory management system The bookstore shall maintain reviews of books and shall allow anyone to upload review comments The bookstore shall maintain ratings on books based on customer inputs Internet Bookstore Requirements 10/7/ © USC-CSSE

University of Southern California Center for Systems and Software Engineering Actors The “Actors” in a use case-style description of a software system are all the people and all the outside hardware and software systems with which the application at hand interacts – the domain model and business workflow too can be used for identification/verification! Some of the Internet Bookstore actors are: The (potential) customer Shipping fulfillment center worker (see the requirements document) Possibly the web sites (i.e., web services) belonging to various shipping companies like USPS, UPS, DHL, etc., i.e., if shipping fulfillment center workers do such things as requesting pickups and checking on deliveries over the Internet. Inventory management worker Various types of administrative employee(s) 10/7/ © USC-CSSE

University of Southern California Center for Systems and Software Engineering Internet Bookstore Use Cases In this part of the lecture we will use Internet Bookstore use cases to introduce the style that we will be using for use case descriptions for the rest of the course. The only actor with which we will be concerned here is the one that we called “User” (or Customer) earlier in the lecture. The only use cases with which we will be concerned are those whose titles are listed on the next slide. That is, we will not consider any (additional) actors or use cases that relate to either shipping fulfillment or inventory management Of course complete analysis & design of the Internet Bookstore application requires that all actors and use cases be dealt with. 10/7/ © USC-CSSE

University of Southern California Center for Systems and Software Engineering Internet Bookstore – A few Use Cases Open Account Log In Search by Author Browse List of Books Edit Content of Shopping Cart Check Out Track Recent Orders Cancel Order 10/7/ © USC-CSSE

University of Southern California Center for Systems and Software Engineering Use Case Descriptions The part of a use case description that relates what happens when everything goes right is called the “basic course” or the “sunny day course” The part of a use case description that relates what happens when something goes wrong is called an “alternate course” or a “rainy day course.” The next slide shows the basic course of the Internet Bookstore’s Open Account use case in the style that we will be using. 10/7/ © USC-CSSE

University of Southern California Center for Systems and Software Engineering 1.The system displays the New Account Page. 2.The Customer types his or her name, an address, and a password (twice), and then presses the Create Account button. 3.The system ensures that the Customer has provided valid data and then adds an Account to the Master Account Table using that data. 4.The system then returns the Customer to the Home Page Open Account Use Case: Basic Course 10/7/ © USC-CSSE

University of Southern California Center for Systems and Software Engineering Open Account Use Case: Basic Course (cont.) As indicated on a previous slide, a use case’s “basic course” is a description of how the relevant actor(s) and the application interact when / if everything goes right e.g., in this case if the customer, attempting to create a new account: –types his/her name –types a syntactically valid address –types a sufficiently long password –types exactly the same password for a second time –has typed a name and an address that don’t already correspond to an Internet Bookstore account 10/7/ © USC-CSSE

University of Southern California Center for Systems and Software Engineering Open Account Use Case: Alternate Courses The next slide shows what seem to be five different alternate courses for the Open Account use case. A use case’s “alternative courses” are descriptions of how the application (system) reacts when the actor doesn’t do “the right thing,” 10/7/ © USC-CSSE

University of Southern California Center for Systems and Software Engineering If the Customer did not provide a name, the system displays an error message to that effect and prompts the Customer to type a name. If the Customer provided an address that's not in the correct form, the system displays an error message to that effect and prompts the Customer to type a different address. If the Customer provided a password that is too short, the system displays an error message to that effect and prompts the Customer to type a longer password. If the Customer did not type the same password twice, the system displays an error message to that effect and prompts the Customer to type the password correctly the second time. If the account is already in the master account table, notify the user. Open Account Use Case: Alternate Courses 10/7/ © USC-CSSE

University of Southern California Center for Systems and Software Engineering Alternate Courses (cont.) A few slides back we suggested that there appear to be five alternate courses. There are actually = 31 alternate courses because: –there are 5 independent binary outcomes that are under the user’s control: valid name vs. invalid name valid address vs. invalid address valid password vs. invalid password identical passwords vs. non-identical passwords new name and address vs. name and address corresponding to existing account –So, there are 2 5 = 32 different possible outcomes, only one of which is the basic course –So there are 31 different possible alternate courses But, when there are ‘N’ independent (sequentially tested) binary outcomes then we will always write the alternate courses as a list of N elements, each starting with an “if”. 10/7/ © USC-CSSE

University of Southern California Center for Systems and Software Engineering Alternate Courses (cont.) A serious cause of software development failure is failure to identify and document all alternate courses of every use case An equally serious cause of software development failure is basic and alternate courses written in incomplete / unclear / ambiguous English – or whatever language is being used So, be very careful about these two issues and review your work multiple times before considering it to be done. (In teams, it would be best to have multiple team members check for the two issues listed above – IIV&V?) 10/7/ © USC-CSSE

University of Southern California Center for Systems and Software Engineering More on Use Cases In some approaches to OOA&D, use cases are at a higher, less implementation-oriented level, than the ones we’re using. (In some approaches use cases almost look like restatements of the requirements.) In the approach that we’ll be using: –the GUI and the uses cases will be developed iteratively, in parallel with one another –and…the use cases will, if done properly, spell out, in full clear detail, what happens for each possible type of interaction that the actor can have with the application. 10/7/ © USC-CSSE

University of Southern California Center for Systems and Software Engineering Additional Internet Bookstore Customer’s Use Cases On the following slides we show the basic and alternative courses of the following two additional Internet Bookstore customer use cases, i.e., the: –Log In use case –Search by Author use case 10/7/ © USC-CSSE

University of Southern California Center for Systems and Software Engineering Basic Course 1.The Customer clicks the Log In button on the Home Page. 2.The System displays the Login Page. 3.The Customer enters his or her user ID and password and then clicks the Log In button. 4.The system validates the login information against the persistent Account data and then returns the Customer to the Home Page. Log In Use Case 10/7/ © USC-CSSE

University of Southern California Center for Systems and Software Engineering If the Customer clicks the New Account button on the Login Page, the system invokes the Open Account use case. If the Customer clicks the Reminder Word button on the Login Page, the system displays the reminder word stored for that Customer, in a separate dialog box. When the Customer clicks the OK button, the system returns the Customer to the Login Page. If the Customer enters a user ID that the system does not recognize, the system displays a message to that effect and prompts the Customer to either enter a different ID or click the New Account button. If the Customer enters an incorrect password, the system displays a message to that effect and prompts the Customer to reenter his or her password. If the Customer enters an incorrect password three times, the system displays a page telling the Customer that he or she should contact customer service, and also freezes the Login Page. Log In Use Case: Alternate Courses 10/7/ © USC-CSSE

University of Southern California Center for Systems and Software Engineering Search by Author Use Case: Basic Course 1.The Customer types the name of an Author on the Search Page and then clicks the Search button. 2.The system ensures that the Customer typed a valid search phrase, and then searches the Catalog and retrieves all of the Books with which that Author is associated. 3.The system then retrieves the important details about each Book, and creates a Search Results object with that information. 4.Then the system displays the list of Books on the Search Results Page, with the Books listed in reverse chronological order by publication date. Each entry has a thumbnail of the Book's cover, the Book's title and authors, the average Rating, and an Add to Shopping Cart button. 5.The Customer presses the Add to Shopping Cart button for a particular Book. 6.The system passes control to the Add Item to Shopping Cart use case. 10/7/ © USC-CSSE

University of Southern California Center for Systems and Software Engineering Search by Author Use Case Alternate Courses If the Customer did not type a search phrase before pressing the Search button, the system displays an error message to that effect and prompts the Customer to type a search phrase. If the system was unable to find any Books associated with the Author that the Customer specified, the system displays a message to that effect and prompts the Customer to perform a different search. If the Customer leaves the page in a way other than by pressing an Add to Shopping Cart button, the system returns control to the use case from which this use case received control. 10/7/ © USC-CSSE

University of Southern California Center for Systems and Software Engineering Use Cases in the SSAD 10/7/2009© USC-CSSE IdentifierUC # Purpose Requirements Development Risks Pre-conditions Post-conditions Seq#Actor’s ActionSystem’s Response 1 2 … n Use-case/ ‘Process’ description Sequence of Actions – Basic/Alternate courses

University of Southern California Center for Systems and Software Engineering GUI Prototyping 10/7/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering GUI Prototyping – What? Based on the use-case descriptions you must come up with a first-cut GUI Mockup/Prototype This ‘first-cut’ will explicitly show the intended layout of the GUI – what all you intend to show and in what form and how you lay it out It is extremely valuable to have GUI Design Principles be a part of prototyping from day one – examples of these were shown in the lecture on User Interfaces It is very likely that on seeing the GUI Mockups the stakeholders realize what is missing or can think of new features that the system should have. This could influence the requirements and/or architecture! 10/7/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering GUI Prototyping – Why? Helps early mitigation of the IKIWISI Risk (I’ll know it when I’ll see it) The stakeholders get ‘early feedback’ as to what the system will look like – along with early participation Remember User Interface (UI) is what the user sees of the application and uses to interact with it This is ‘extremely’ iterative! Aesthetics NEED NOT be a part at this stage – but can be so once the stakeholders have agreed to the proposed UIs (usually done by UI Aesthetic experts!) 10/7/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering GUI Prototyping – How? There are various approaches to ‘creating’ prototypes: –Using tools such as iRise (recommended for web based 577 projects) or other commercial tools like ‘Balsamiq.com’ (the mockups shown a few slides back were done using that) –‘Code’ it or use GUI Drag/Drop tools (Quite Common) –PowerPoint/Visio (NOT scalable) –Whiteboard techniques (Very tedious and requires constant presence of stakeholder(s)) –Various ‘Imaging Tools’ i.e., Photoshop, Paintbrush (Please DON’T try – extremely tedious!) –Post-its?  Each can act as a UI Widget – has to be augmented with the Whiteboard techniques 10/7/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering Another Example 10/7/2009© USC-CSSE If there exists a User Interface, irrespective of the device on which it will be displayed you MUST prototype it (i.e., create early mockups)

University of Southern California Center for Systems and Software Engineering GUI and Use-Cases When the GUIs get finalized (with a relatively high level of confidence) the use-case text MUST be refined too! The use-cases should then explicitly refer the elements in the GUI Mockups Advantages: –Helps make the English Use-case text descriptions less ambiguous (almost negligible!) and more precise –Developers are more aware of ‘what’ to build and what is expected from the application 10/7/2009© USC-CSSE

University of Southern California Center for Systems and Software Engineering How to build what to build? Currently we have seen how to reach towards unambiguous (or less ambiguous) Use-case texts The use-case descriptions need to be ‘further analyzed’ to identify what classes would become a part of the analysis/design model These classes would already exist in part from the Domain Model* and more would be identified as result This ‘analysis’ is performed using an approach known as Robustness Analysis which will be covered in the next OOAD lecture 10/7/2009© USC-CSSE *The DM is thus ‘transformed’ into analysis/design classes and is NO longer called a DM