Financial Accounting


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Financial Accounting

  1. 1. Architecture, Deployment Diagrams, Web Modeling Elizabeth Bigelow CS-15499C October 6, 2000
  2. 2. Today New schedule Project next steps Feedback Architecture in the object oriented sense Deployment diagrams Event systems
  3. 3. Schedule Please note that schedule for presentations and mentoring sessions has been updated on the web Teams D, E, F present Wednesday Mentoring sessions on Friday Two lectures on Monday
  4. 4. Some thoughts Why do a particular diagram…  UML diagrams allow you to look at a problem from different perspectives  Keeping the details straight on a big project is a major problem  Big advantage in entering data once (if possible)  Diagrams are not totally orthagonal, but at least parts that are can be tracked
  5. 5. Why…. Payoff on modeling  analysis & cross-checking  communication Bicycle for the mind Combination of modeling and human analysis can yield much more than narrow area of model Trick is to know when to stop
  6. 6. Project Next Steps and Feedback First presentations were in general very good The primary goal was to convey to the class what the project was about Most teams participated evenly Event systems requested were not included
  7. 7. Next steps Refine class association diagrams to show all attributes and methods Create behavioral diagrams for key areas (particularly those that can change state on the site, as opposed to sheer display) Create deployment and web models Analyze diagrams individually and together to see what has to be changed for implementation
  8. 8. Presentations Teams D, E, F should give presentations much like the previous ones, but show their diagrams at a greater level of development (particularly behavioral) All teams should create deployment and web diagrams for mentoring session and be prepared to show results of cross diagram analysis
  9. 9. Analysis Consistency checking (create forms for yourself to document your checks. Some people find it helpful to use copies of diagrams) Support for major queries and processes Document potential run time problems Determine whether implementation object model should change  Will your code track exactly to the model? Why or why not
  10. 10. Architecture and UML In UML, there are five views  Structural view (Class Diagrams, Object Diagrams)  Implementation View (Component Diagrams)  Environment View (Deployment Diagrams)  Behavioral View (Sequence Diagrams, Collaboration Diagrams, Statechart Diagrams, Activity Diagrams)
  11. 11. Component Diagrams Show relationships and dependencies among sets of code without respect to actual physical placement of code Use only when there is a design issue
  12. 12. Deployment Diagrams Called “environment” diagram Shows actual physical organization of computation units and connectors Appropriate to do at this stage--when user requirements are fairly well articulated May surface practical problems Should use for “what if’s” (volume, network failures, etc.)
  13. 13. Deployment Diagrams
  14. 14. The Web To date, we’ve looked at application objects Now, we need to look at objects and components in terms of building web applications
  15. 15. Object oriented? Fundamental component is the page Web servers distribute pages of information to browsers Browser acts as generalized user interface container (specifics defined by each page’s content) Pages may be a combination of static HTML and dynamic scripted pages (ASP)
  16. 16. Scripted Pages Scripted pages contain code executed by web server (scripting engine or page filter) ultimately building an HTML formatted page Page is sent back to browser that requests it
  17. 17. Web Client Server Connection exists only during a page request (connection is broken once the request is fulfilled) Business logic on the server is only activated by the execution of scripts inside the pages requested by the browser Ultimate result is to update the business state of the server and prepare an HTML formatted page to the requesting browser
  18. 18. Issues Business objects are not always accessible when handling individual requests
  19. 19. Client Scripting As opposed to server side (procedural), are event driven Have no access to server resources
  20. 20. Forms Necessary to collect information Each form associated with an action page Web server finds page and executes the page’s code
  21. 21. Components Server -- there may be an intermediate tier with business logic Client may have components for execution on clients machine. In order model these effectively, UML extensions have to be used
  22. 22. Stereotypes Special types of classes and relationships for special, well defined purposes Use only when necessary _Really_ necessary for effective web modeling See 62jsp