1 / 54

Some slides adapted from:

SA Capstone Requirements and Design Week 6 SYST36367 - Winter 2013 Instructors: Jerry Kotuba & Joe Varrasso. Some slides adapted from: Systems Analysis and Design in a Changing World, 6th Edition, Satzinger , Jackson, Burd , CENGAGE Learning, 2012. Lesson Objectives.

naoko
Télécharger la présentation

Some slides adapted from:

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. SA Capstone Requirements and DesignWeek 6SYST36367 - Winter 2013Instructors: Jerry Kotuba & Joe Varrasso Some slides adapted from: Systems Analysis and Design in a Changing World, 6th Edition, Satzinger, Jackson, Burd, CENGAGE Learning, 2012

  2. Lesson Objectives • Analysis versus Design • Designing the software architecture • Design Principles • Selecting software frameworks and components • Design Patterns • Design Class Diagrams • Sequence Diagrams

  3. Analysis Objectives versus Design Objectives Understand WHAT is required Design HOW to meet requirements Systems Analysis and Design in a Changing World, 6th Edition

  4. Analysis vs. Design Models Systems Analysis and Design in a Changing World, 6th Edition

  5. UML Requirements vs. Design ModelsDiagrams are enhanced and extended Systems Analysis and Design in a Changing World, 6th Edition

  6. Two Levels of Design • Architectural Design • Broad design of the overall system structure • Also called General Design and Conceptual Design • Detailed Design • Low level design that includes the design of the specific program details • Design of each use case • Design of the database • Design of user and system interfaces • Design of controls and security Systems Analysis and Design in a Changing World, 6th Edition

  7. Design Activities:Design the application architecture and software • Partition system into subsystems • Define software architecture • Two layer, three layer or model-view-controller • Detailed design of each use case • Design class diagrams • Sequence diagrams • State machine diagrams Systems Analysis and Design in a Changing World, 6th Edition

  8. Design Activities:Design the system interfaces • Information systems interact with many other systems, internal and external • Much more integration now • System interfaces connect with other systems in many different ways • Save data another system uses • Read data another system saved • Real time request for information • Software services Systems Analysis and Design in a Changing World, 6th Edition

  9. Identifying System InterfacesInputs/outputs with minimal human intervention • Inputs from and outputs to other systems • These are direct interfaces with other information systems, normally formatted as network messages. • Highly automated inputs and outputs • These are captured by devices (such as scanners) or generated by persons who start a process that proceeds without further human intervention. • Inputs and outputs to external databases • These can supply input to or accept output from a system. Systems Analysis and Design in a Changing World, 6th Edition

  10. Identifying System Interfaces Systems Analysis and Design in a Changing World, 6th Edition

  11. XML for System Interfaces • Extensible Markup Language (XML) -- extension of HTML that embeds self-defining data structures within textual messages • XML tags -- character sequences (such as <name> and </name>) that define the beginning, end, and meaning of the text that appears between them Systems Analysis and Design in a Changing World, 6th Edition

  12. Defining System Inputs Details • Sequence Diagram • Details for messages Systems Analysis and Design in a Changing World, 6th Edition

  13. Design the EnvironmentThe design activity now in more detail • Design for Internal Deployment • Stand alone software systems • Run on one device without networking • Internal network-based systems • Local area network, client-server architecture • Desktop applications and browser-based applications • Three-layer client server architecture • View layer, domain layer, and data layer • Desktop and browser based applications Systems Analysis and Design in a Changing World, 6th Edition

  14. Network DiagramInternal Network System Systems Analysis and Design in a Changing World, 6th Edition

  15. Three Layer Architecture • Three Layer Client-Server Architecture • a client/server architecture that divides an application into view layer, business logic layer, and data layer • View layer • the part of the three-layer architecture that contains the user interface • Business logic layer or domain layer • the part of a three-layer architecture that contains the programs that implement the business rules and processes • Data layer • the part of a three-layer architecture that interacts with the data Systems Analysis and Design in a Changing World, 6th Edition

  16. Abstract Three Layer Architecture Systems Analysis and Design in a Changing World, 6th Edition

  17. Internal Deployment withThree Layer Architecture Systems Analysis and Design in a Changing World, 6th Edition

  18. Design the Environment(continued) • Design for External Deployment • Configuration for Internet deployment • Advantages and risks • Hosting Alternatives for Internet deployment • Colocation • Managed services • Virtual Servers • Cloud computing • Diversity of Client Devices with Internet deployment • Full size, tablets and notebooks, smart phones Systems Analysis and Design in a Changing World, 6th Edition

  19. Configuration for Internet Deployment Systems Analysis and Design in a Changing World, 6th Edition

  20. Configuration for Internet Deployment • Advantages • Accessibility—Web-based applications are accessible to a large number of potential users (including customers, suppliers, and off-site employees). • Low-cost communication—The high-capacity networks that form the Internet backbone were initially funded primarily by governments. Traffic on the backbone networks travels free of extra charges to the end user. Connections to the Internet can be purchased from a variety of private Internet service providers at relatively low costs. • Widely implemented standards—Web standards are well known, and many computing professionals are already trained in their use. Systems Analysis and Design in a Changing World, 6th Edition

  21. Configuration for Internet Deployment • Potential Problems • Security—Web servers are a well-defined target for security breaches because Web standards are open and widely known. Wide-scale interconnection of networks and the use of Internet and Web standards make servers accessible to a global pool of hackers. • Throughput—When high loads occur, throughput and response time can suffer significantly. The configuration must support not only daily average users but also a peak-load number of users. • Changing standards—Web standards change rapidly. Client software is updated every few months. Developers of widely used applications are faced with a dilemma: Use the latest standards to increase functionality or use older standards to ensure greater compatibility with older user software. Systems Analysis and Design in a Changing World, 6th Edition

  22. Performance improved by multiple server configurations Systems Analysis and Design in a Changing World, 6th Edition

  23. Hosting Alternatives for Internet Deployment • Hosting: • Running and maintaining a computer system on someone’s behalf where the application software and the database reside • The process of providing physical servers at a secure location and selling those services to other businesses that wish to deploy Web sites • Issues when considering hosting alternatives • Reliability, security, physical facilities, staff, potential for growth and cost Systems Analysis and Design in a Changing World, 6th Edition

  24. Hosting Alternatives for Internet Deployment (continued) Systems Analysis and Design in a Changing World, 6th Edition

  25. Design for Remote, Distributed Environment • Two interfaces to same Web app for internal vs. external access • Back end, Front end UI to same Web app • Not as secure • Virtual private network (VPN) • Closed network with security and closed access built on top of a public network (Internet) Systems Analysis and Design in a Changing World, 6th Edition

  26. Virtual Private Network (VPN) Systems Analysis and Design in a Changing World, 6th Edition

  27. RMO’s Current Technology Architecture Systems Analysis and Design in a Changing World, 6th Edition

  28. Object-Oriented Program FlowThree Layer Architecture Systems Analysis and Design in a Changing World, 6th Edition

  29. Fundamental Design Principles • Coupling • A quantitative measure of how closely related classes are linked (tightly or loosely coupled) • Two classes are tightly coupled of there are lots of associations with another class • Two classes are tightly coupled if there are lots of messages to another class • It is best to have classes that are loosely coupled • If deciding between two alternative designs, choose the one where overall coupling is less Systems Analysis and Design in a Changing World, 6th Edition

  30. Fundamental Design Principles • Cohesion • A quantitative measure of the focus or unity of purpose within a single class (high or low cohesiveness • One class has high cohesiveness if all of its responsibilities are consistent and make sense for purpose of the class (a customer carries out responsibilities that naturally apply to customers) • One class has low cohesiveness if its responsibilities are broad or makeshift • It is best to have classes that are highly cohesive • If deciding between two alternative designs, choose the one where overall cohesiveness is high Systems Analysis and Design in a Changing World, 6th Edition

  31. Fundamental Design Principles • Protection from Variations • A design principle that states parts of a system unlikely to change are separated (protected) from those that will surely change • Separate user interface forms and pages that are likely to change from application logic • Put database connection and SQL logic that is likely to change in a separate classes from application logic • Use adaptor classes that are likely to change when interfacing with other systems • If deciding between two alternative designs, choose the one where there is protection from variations Systems Analysis and Design in a Changing World, 6th Edition

  32. Fundamental Design Principles • Indirection • A design principle that states an intermediate class is placed between two classes to decouple them but still link them • A controller class between UI classes and problem domain classes is an example • Supports low coupling • Indirection is used to support security by directing messages to an intermediate class as in a firewall • If deciding between two alternative designs, choose the one where indirection reduces coupling or provides greater security Systems Analysis and Design in a Changing World, 6th Edition

  33. Fundamental Design Principles • Object Responsibility • A design principle that states objects are responsible for carrying out system processing • A fundamental assumption of OO design and programming • Responsibilities include “knowing” and “doing” • Objects know about other objects (associations) and they know about their attribute values. Objects know how to carry out methods, do what they are asked to do. • Note that CRC cards and the design in the next chapter involve assigning responsibilities to classes to carry out a use case. • If deciding between two alternative designs, choose the one where objects are assigned responsibilities to collaborate to complete tasks (don’t think procedurally). Systems Analysis and Design in a Changing World, 6th Edition

  34. Software Components and Frameworks • Time to Market is paramount in today’s competitive marketplace • Selecting powerful and tested frameworks and components can save lots of development time • Systems Analysts often need to participate in “Buy versus Build” decisions regarding components and frameworks • Capstone is designed to reflect industry best practices. So your team should look for components and frameworks that can speed your development and improve your product! • Past groups have used several components and frameworks including: • CakePHP, jQuery, Kendo UI, HTML5, PhoneGap, Google Web Toolkit (GWT), Microsoft Entity Framework, ASP.NET MVC, ASP.NET AJAX Control Toolkit, Crystal Reports, etc.

  35. Design Patterns • Design Pattern—standard design techniques and templates that are widely recognized as good practice • For common design/coding problems, the design pattern suggests the best way to handle the problem. • They are written up in design pattern catalogs/references. Include: • Pattern name • Problem that requires solution • The pattern that solves the problem • An example of the pattern • Benefits and consequences of the a pattern Systems Analysis and Design in a Changing World, 6th Edition

  36. Design Patterns • Design patterns became widely accepted after the publication of Elements of Reusable Object-Oriented Software,(1996) by Gamma et al (the “Gang of Four”) • There are architectural design patterns talked about already • Three layer or model-view-controller architecture • The first example of a programming design pattern shown is the Controller Pattern. • Problem is deciding how to handle all of the messages from the view layer to classes in the problem domain layer to reduce coupling • Solution is to assign one class between the view layer and the problem domain layer that receives all messages and acts as a switchboard directing messages to the problem domain Systems Analysis and Design in a Changing World, 6th Edition

  37. Controller PatternFirst step toward multilayer architectureMore design patterns are at the end of the chapter Systems Analysis and Design in a Changing World, 6th Edition

  38. OO Detailed Design StepsChapters 10 and 11 Systems Analysis and Design in a Changing World, 6th Edition

  39. First Cut Design Class Diagram • Proceed use case by use case, adding to the diagram • Pick the domain classes that are involved in the use case (see preconditions and post conditions for ideas) • Add a controller class to be in charge of the use case • Determine the initial navigation visibility requirements using the guidelines and add to diagram • Elaborate the attributes of each class with visibility and type • Note that often the associations and multiplicity are removed from the design class diagram as in text to emphasize navigation, but they are often left on Systems Analysis and Design in a Changing World, 6th Edition

  40. Start with Domain ClassDiagramRMO Sales Subsystem Systems Analysis and Design in a Changing World, 6th Edition

  41. Create First Cut Design ClassDiagramUse Case Create phone sale with controller added Systems Analysis and Design in a Changing World, 6th Edition

  42. Use Case Realization with Sequence Diagrams • Use case realization—the process of elaborating the detailed design of a use case with interaction diagrams • Two types of interaction diagrams • UML sequence diagram (emphasized in text) • UML communication diagram (also introduced) • Sequence diagrams, aka use case realization sequence diagrams, extend the system sequence diagram (SSD) to show: • View layer objects • Domain layer objects (usually done first) • Data access layer objects Systems Analysis and Design in a Changing World, 6th Edition

  43. Start with System Sequence Diagram (SSD)Use case Create customer account Systems Analysis and Design in a Changing World, 6th Edition

  44. Sequence Diagram to show View Layer and Part of Problem Domain Layer Systems Analysis and Design in a Changing World, 6th Edition

  45. Notes of Expanded Sequence Diagram • This is a two layer architecture, as the domain class Customer knows about the database and executes SQL statements for data access • Three layer design would add a data access class to handle the database resulting in higher cohesiveness and loose coupling • Note :CustomerForm is an object of the CustomerForm class, :CustomerHandler is an object of the CustomerHandler class playing the role of a controller stereotype (both underlined becuase they are objects) • aC:Customer is an object of the Customer class known by reference variable named aC • Note: the create message to aC:Customer points to the object symbol to indicate create Systems Analysis and Design in a Changing World, 6th Edition

  46. Create Customer Account Use CaseStart with domain model for Customer Account Subsystem Systems Analysis and Design in a Changing World, 6th Edition

  47. Create Customer Account Use CaseFirst cut design class diagram for use caseSelect needed classes, elaborate attributes, add controller, and add navigation visibility Systems Analysis and Design in a Changing World, 6th Edition

  48. Create Customer Account Use CaseFirst cut sequence diagram expanding SSD, adding controller, and adding needed classes Systems Analysis and Design in a Changing World, 6th Edition

  49. Create Customer Account Use CaseAdd messages and activation to complete collaborationThis is just the domain layerThese domain classes handle data access, so this is a two layer architecture Systems Analysis and Design in a Changing World, 6th Edition

  50. Assumptions • Perfect technology assumption—First encountered for use cases. We don’t include messages such as the user having to log on. • Perfect memory assumption—We have assumed that the necessary objects were in memory and available for the use case. In multilayer design to follow, we do include the steps necessary to create objects in memory. • Perfect solution assumption—The first-cut sequence diagram assumes no exception conditions. • Separation of responsibilities—Design principle that recommends segregating classes into separate components based on the primary focus, such as user interface, domain, and data access Systems Analysis and Design in a Changing World, 6th Edition

More Related