Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Lecture Note for Introduction Class

271 views

Published on

  • Be the first to comment

  • Be the first to like this

Lecture Note for Introduction Class

  1. 1. Architecture, DeploymentDiagrams, Web ModelingElizabeth BigelowCS-15499COctober 6, 2000
  2. 2. TodayNew scheduleProject next stepsFeedbackArchitecture in the object orientedsenseDeployment diagramsEvent systems
  3. 3. SchedulePlease note that schedule forpresentations and mentoring sessionshas been updated on the webTeams D, E, F present WednesdayMentoring sessions on FridayTwo lectures on Monday
  4. 4. Some thoughtsWhy do a particular diagram… UML diagrams allow you to look at aproblem from different perspectives Keeping the details straight on a big projectis a major problem Big advantage in entering data once (ifpossible) Diagrams are not totally orthagonal, but atleast parts that are can be tracked
  5. 5. Why….Payoff on modeling analysis & cross-checking communicationBicycle for the mindCombination of modeling and humananalysis can yield much more thannarrow area of modelTrick is to know when to stop
  6. 6. Project Next Steps andFeedbackFirst presentations were in general verygoodThe primary goal was to convey to theclass what the project was aboutMost teams participated evenlyEvent systems requested were notincluded
  7. 7. Next stepsRefine class association diagrams to show allattributes and methodsCreate behavioral diagrams for key areas(particularly those that can change state onthe site, as opposed to sheer display)Create deployment and web modelsAnalyze diagrams individually and together tosee what has to be changed forimplementation
  8. 8. PresentationsTeams D, E, F should givepresentations much like the previousones, but show their diagrams at agreater level of development(particularly behavioral)All teams should create deployment andweb diagrams for mentoring sessionand be prepared to show results ofcross diagram analysis
  9. 9. AnalysisConsistency checking (create forms foryourself to document your checks. Somepeople find it helpful to use copies ofdiagrams)Support for major queries and processesDocument potential run time problemsDetermine whether implementation objectmodel should change Will your code track exactly to the model? Why orwhy not
  10. 10. Architecture and UMLIn UML, there are five views Structural view (Class Diagrams, ObjectDiagrams) Implementation View (ComponentDiagrams) Environment View (Deployment Diagrams) Behavioral View (Sequence Diagrams,Collaboration Diagrams, StatechartDiagrams, Activity Diagrams)
  11. 11. Component DiagramsShow relationships and dependenciesamong sets of code without respect toactual physical placement of codeUse only when there is a design issue
  12. 12. Deployment DiagramsCalled “environment” diagramShows actual physical organization ofcomputation units and connectorsAppropriate to do at this stage--when userrequirements are fairly well articulatedMay surface practical problemsShould use for “what if’s” (volume, networkfailures, etc.)
  13. 13. Deployment Diagrams
  14. 14. The WebTo date, we’ve looked at applicationobjectsNow, we need to look at objects andcomponents in terms of building webapplications
  15. 15. Object oriented?Fundamental component is the pageWeb servers distribute pages of informationto browsersBrowser acts as generalized user interfacecontainer (specifics defined by each page’scontent)Pages may be a combination of static HTMLand dynamic scripted pages (ASP)
  16. 16. Scripted PagesScripted pages contain code executedby web server (scripting engine or pagefilter) ultimately building an HTMLformatted pagePage is sent back to browser thatrequests it
  17. 17. Web Client ServerConnection exists only during a page request(connection is broken once the request isfulfilled)Business logic on the server is only activatedby the execution of scripts inside the pagesrequested by the browserUltimate result is to update the business stateof the server and prepare an HTML formattedpage to the requesting browser
  18. 18. IssuesBusiness objects are not alwaysaccessible when handling individualrequests
  19. 19. Client ScriptingAs opposed to server side (procedural),are event drivenHave no access to server resources
  20. 20. FormsNecessary to collect informationEach form associated with an actionpageWeb server finds page and executesthe page’s code
  21. 21. ComponentsServer -- there may be an intermediatetier with business logicClient may have components forexecution on clients machine.In order model these effectively, UMLextensions have to be used
  22. 22. StereotypesSpecial types of classes and relationships forspecial, well defined purposesUse only when necessary_Really_ necessary for effective webmodelingSeewww.rational.com/products/whitepapers/100462jsp

×