University of Southern California Center for Systems and Software Engineering CS577a: SSAD in DC Nupul Kukreja 6/4/ © USC-CSSE

University of Southern California Center for Systems and Software Engineering Agenda Technology specific design – relatively low level design –Emphasis on class diagrams Review of the common mistakes in SSAD for the FC/DC-P –Artifact and Information Diagram – Re-review –Use case descriptions – common mistakes –Other issues that teams may have A workshop like session for both design classes and SSAD’s common mistakes 6/4/2016© USC-CSSE

University of Southern California Center for Systems and Software Engineering Roadmap so far Previous lecture(s): –Use-case text  Robustness Analysis –Robustness diagrams  Sequence Diagrams –Sequence diagrams  Class Diagrams Class diagrams were relatively high level and ‘factored’ into: –View Classes –‘Control Classes’ (i.e. Application/Business) –Data classes 6/4/2016© USC-CSSE

University of Southern California Center for Systems and Software Engineering Technology Specific Design These are ‘relatively high level’ low level designs – confusing? No need to drill down to every low level detail about the design – as yet (will be done in 577b) –Ex.: All the method parameters and the associated data types need NOT be identified in totality If using Java, then stating if a class inherits from JFrame and the associated attributes like JButtons etc., would be required We shall see ‘examples by doing’ in today’s lecture 6/4/2016© USC-CSSE

University of Southern California Center for Systems and Software Engineering Technology Specific Design – Multiple Types of Views Different ‘types’ of views exist as per the type of the application –Web based: Views = Web Pages –Desktop Application: Views = Screen Windows –Mobile Application: Either or both of the above ‘Somewhat easy’ to capture Views of Desktop applications in UML diagrams – since they are just ‘classes’ offered by the underlying development framework How to capture ‘pages’? 6/4/2016© USC-CSSE

University of Southern California Center for Systems and Software Engineering Capturing ‘Pages’ Pages are either Static or Dynamic There are certain ‘hybrids’ so to speak: –The page is a form which has a fixed layout of the form fields – static as far as layout is concerned –The ‘content’ of the fields may be dynamically generated or be fetched on demand from the application logic classes (or directly from data classes in case of a 2-tiered architecture) Web pages are actually “Complex Objects”: – Javascripts, Flash/ActiveX Objects, Forms, Applets, PHP/JSP/ASP-code etc., are in ONE page!!! Capturing them in UML is NOT straightforward 6/4/2016© USC-CSSE

University of Southern California Center for Systems and Software Engineering Capturing Pages – II EACH of the previously mentioned components of a page are ‘typically’ CODED as a single server side page!! (*.jsp or *.asp or *.php pages) On the ‘server-side’ the page has access to ALL server components i.e., application logic classes, data classes etc., On the ‘client side’ the page is now an HTML page having access ONLY to client accessible methods/objects (JavaScript, VBScript, Form submission etc.,) How do we then effectively model/capture this? 6/4/2016© USC-CSSE

University of Southern California Center for Systems and Software Engineering Capturing Pages – III SIMPLEST solution: UML Stereotypes –Use the following stereotypes for the Boundary classes > or > or > or > etc., May NOT always be the cleanest solution, but may suffice for relatively simple pages Assume there exists a validateForm() method (client side JavaScript) and a JSP method fetchProductInfo(Prod_id) (for server side scripting) –Physically ‘coded’ in same.jsp page but how would this be ‘better’ modeled? Should you ‘throw’ all of these in ONE stereotyped class? 6/4/2016© USC-CSSE

University of Southern California Center for Systems and Software Engineering Capturing Pages - IV A suggested approach* is to ‘break up’ the ‘Page’ into > and > The latter could be placed in the ‘Business Logic Layer’ and the former in the View Layer with the two associated with the stereotyped > association (a server side page builds a client side page – conceptually) The > can be ‘associated’ to other pages via a > association! You could also have > or > as ‘classes’ that form a web page!! Stereotypes help ‘extend’ UML conveniently 9 * Building Web Applications with UML, Jim Conallen (Rational Software) 6/4/2016© USC-CSSE

University of Southern California Center for Systems and Software Engineering Capturing Pages – V (Examples) 10 These images are take from “Modeling Web Applications with UML, Jim Conallen, October 1999/Vol. 42, No. 10 COMMUNICATIONS OF THE ACM, Pages 63-70” A relatively high level ‘fancy diagram’ view showing the pages and their associations. The RED Cog Page is a ‘dynamic server side page’ – pay more attentions to the associations The {productID} is an HTTP attribute ‘sent’ to the server side page which then > the corresponding ProductDetail Page 6/4/2016© USC-CSSE

University of Southern California Center for Systems and Software Engineering 6/4/2016© USC-CSSE This is an example of ‘Client Page’ Modeling -Pay attention to the Stereotyped classes and the corresponding associations. -This diagram CLEARLY shows all the technology specific aspects of a particular Web Page!! -See the stereotyped attributes of the EventDetail class showing the ‘form fields’ that are displayed on the form

University of Southern California Center for Systems and Software Engineering 6/4/2016© USC-CSSE Modeling JavaScript as a separate class MAY BE totally unnecessary! They could just as well be ‘methods’ of > e.g., validate() -Do this ONLY if JavaScript is NOT very trivial and you need Scripts for ‘specific’ parts of the page – Like updating Meeting Events and Participants in this example

University of Southern California Center for Systems and Software Engineering 6/4/2016© USC-CSSE Very Similar to Client Pages!! -Only difference is the associations are now to the classes in the ‘Business Logic Layer’ (or Data Layer) -Only a > association needs to be modeled between the EventDetails > on the client page and the UpdateMeeting >

University of Southern California Center for Systems and Software Engineering 6/4/2016© USC-CSSE > -Pay close attention to how the client and server pages interact -The red ‘oval’ is emphasizing ‘multiple’ TextBoxes exist using the Array Notation [m..n] -The > and > stereotyped associations help make a ‘cleaner’ model

University of Southern California Center for Systems and Software Engineering Capturing the ‘Pages’ – Points to Note As seen capturing pages may/may not be relatively straight forward If you’ve already ‘prototyped’ the GUI and is okay-ed by the stakeholders, you don’t need to explicitly recapture the fields in the corresponding HTML classes ( > or >) If your pages have ONLY ‘static’ content (text/images only) you need not model any attributes/methods of the corresponding class – only the stereotyped class and the > associations between them If static pages contain JavaScripts, Google Calendar/Maps, Applets, ActiveX Objects, Flash animations etc., then explicitly capture them in the technology specific model 15 6/4/2016© USC-CSSE

University of Southern California Center for Systems and Software Engineering Capturing the ‘Pages’ – Points to Note (cont’d) Common confusion – “I have a menu on top of the page that allows the user to go from any page to any other page” –Modeling implication: A spider web model – everything > to everything else!! Solution: Take hints from your navigational flow diagram and model the relations accordingly. If everything can be connected, then state it as a “UML Note” and show the most relevant/important associations among the pages 6/4/2016© USC-CSSE

University of Southern California Center for Systems and Software Engineering Technology Specific Modeling Choose the appropriate ‘view modeling’ style based on the type of application (web based or desktop) The robustness analysis and sequence diagrams should provide you with good starting points of the corresponding Boundary, Control (Business Logic (BL)) and Entity classes What ‘technology’ specific aspects are you expected to model in the other 2 layers? (BL and Data) 6/4/2016© USC-CSSE

University of Southern California Center for Systems and Software Engineering TSM – Aspects to Model You should be able to specify, till some extent, the data types of the attributes, specific to the underlying technology (e.g., int, float, String, CString, ArrayList etc., in Java, C++ etc.,) Classes usually communicate by passing ‘data’ through method parameters – capture them, but NOT exhaustively Many external libraries would be used for development (e.g., Apache Commons) – capture which classes talk to ‘which’ classes/packages in the library 6/4/2016© USC-CSSE

University of Southern California Center for Systems and Software Engineering TSM – Aspects to Model (cont’d) Assume a Java desktop application launches a dialog to browse for a file to open It implies that the corresponding class (which would inherit from JFrame) would be dependent on (or associated to) a JDialog class which too needs to be captured –Either your component subclasses from JDialog OR –You use the default functionality and directly instantiate the JDialog class Either case it needs to be captured in TSM 6/4/2016© USC-CSSE

University of Southern California Center for Systems and Software Engineering Hands On One of the most well done SSADs in Fall ‘08 was by Team 8 (AAA Petal Pushers) – we shall see their TSM as a case study /team8/Foundations/SSAD_DCP_F08a_T08_V6. 5.pdf They used ‘component’ separation as opposed to layered (i.e., each component consisted of View, Business Logic and Data Classes) NOTE: This is ONLY for your reference DO NOT DUPLICATE!! 6/4/2016© USC-CSSE

University of Southern California Center for Systems and Software Engineering SSAD – Common Mistakes Artifact and Information Diagram –Almost everyone faltered! –It is like asking you for a DB-Schema in OO notation (if this is ‘easier’ to understand) You MAY NOT store every thing in a DB, Flat files could be used too! In case of Static Web Pages – your ‘persistent’ data IS the boundary class itself! (think about it) –Same problems as we saw on an earlier slide Capturing the ‘Pages’ – Points to Note (cont’d) and same solution too! Capturing the ‘Pages’ – Points to Note (cont’d) 6/4/2016© USC-CSSE

University of Southern California Center for Systems and Software Engineering Use-Case Mistakes Application is running and Database is Initialized or Internet connection is present ARE NOT preconditions for a use-case; they may be so for ‘System Availability’. Extremely ambiguous use cases! No mention of the corresponding UI pages where the actions are expected to happen Lack of complete sentences – some only wrote ‘key words’!!! Preposterous! No mention of the actor who performs the actions at all! 6/4/2016© USC-CSSE

University of Southern California Center for Systems and Software Engineering Hands On We could do a hands on for any of the following (or all if time permits) from any project currently in 577a –Artifact and Information Diagram –Use-case descriptions (drive RA) –Robustness Analysis (RA – drives SD) –Sequence Diagrams (SD – drives CD) –Class Diagrams (CD – drives TSM CD) –TSM – class and deployment diagrams Pick and choose! 6/4/2016© USC-CSSE