1 / 29

Systems Analysis and Design in a Changing World, Fifth Edition

Elements of Systems DesignPART IDeployment Diagrams. What is a Deployment Diagram. The deployment diagram shows how a system will be physically deployed in the hardware environment. Its purpose is to show where the different components of the system will physically run and how they will comm

guinivere
Télécharger la présentation

Systems Analysis and Design in a Changing World, Fifth Edition

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. Systems Analysis and Design in a Changing World, Fifth Edition

    2. Elements of Systems Design PART I Deployment Diagrams

    3. What is a Deployment Diagram The deployment diagram shows how a system will be physically deployed in the hardware environment. Its purpose is to show where the different components of the system will physically run and how they will communicate with each other. Since the diagram models the physical runtime, a system's production staff will make considerable use of this diagram. The notation in a deployment diagram includes the notation elements used in a component diagram, with a couple of additions, including the concept of a node. A node represents either a physical machine or a virtual machine node (e.g., a mainframe node). To model a node, simply draw a three-dimensional cube with the name of the node at the top of the cube. Use the naming convention used in sequence diagrams.

    4. UML Notation for Deployment Diagrams Component Executable module or program Has an application program interface (API) that is available to the outside world Node A physical entity at a specific location Frameset A high-level object that holds items to be displayed by a browser

    6. Deployment Diagram Example The deployment diagram below shows that the users access the Reporting Tool by using a browser running on their local machine and connecting via HTTP over their company's intranet to the Reporting Tool. This tool physically runs on the Application Server named w3reporting.myco.com. The diagram shows the Reporting Tool component drawn inside of IBM WebSphere, which in turn is drawn inside of the node w3.reporting.myco.com. The Reporting Tool connects to its reporting database using the Java language to IBM DB2's JDBC interface, which then communicates to the actual DB2 database running on the server named db1.myco.com using native DB2 communication. In addition to talking to the reporting database, the Report Tool component communicates via SOAP over HTTPS to the Billboard Service.

    7. UML Deployment Diagram Example The three-dimensional boxes represent nodes, either software or hardware. Physical nodes should be labeled with the stereotype device, to indicate that it is a physical device such as a computer or switch. Connections between nodes are represented with simple lines, and are assigned stereotypes such as RMI and message bus to indicate the type of connection.

    8. Concise UML 2 Deployment Diagram A better example is shown in the figure below. Software elements are now simply listed by their physical filenames, information that developers are very likely to be interested in, and thus a more compact diagram is possible. A drum is used as a visual stereotype for the University DB database, making it easier to distinguish on the diagram. Another difference is that the concise version shows less details, not as many tagged values are shown as this information can be captured in either supporting documentation, configuration files, or source code.

    9. Elements of Systems Design PART II Design Patterns

    10. Importance of Design Patterns Standard design templates can speed OO design Patterns can exist at different levels of abstraction At the most concrete level, a class definition with code At the most abstract level, an approach to a problem Patterns should contain five main elements Pattern name, problem, solution, example, benefits and consequences

    11. Pattern description for the controller pattern

    12. Basic Design Patterns The authors of Elements of Reusable Object-Oriented Software (referred to as the Gang of Four) developed a basic classification scheme for patterns The 23 GoF patterns are some of the most fundamental and important patterns in use Scores of other patterns have been defined For example, both Java and .NET have sets of enterprise patterns

    13. Singleton Pattern For classes that must have only one instance, but need to be invoked from several classes and locations within the system The class itself controls the creation of only one instance A static variable of the class refers to the object that is created A class method instantiates the object on the first call, and returns a reference to the object on subsequent calls

    14. Singleton pattern template

    15. Adaptor Pattern Plugs an external class into a system Converts the method calls from within the system to match the method names in the external class A standard solution for protection from variations Insulates the system from frequently changing classes An interface is frequently used to specify and enforce the use of correct method names

    16. Adapter pattern template

    17. Observer pattern Used to handle event-processing and reduce coupling The domain class Allows other classes to subscribe as listeners Publishes the changes to the listeners The windows class Sends a reference of itself to subscribe as a listener Implements the method to be invoked when notified Inherits the method from the listener interface

    20. Observer pattern template

    21. Designing Enterprise-level Systems Enterprise-level systems share components among multiple people or groups in an organization Enterprise-level systems almost always use multiple tiers of computers Can be client/server network-based or Internet based Designed with deployment diagrams A type of implementation diagram that shows physical components across different locations

    22. Simple Internet Architecture Used for viewing static information The browser component executes on the client computer The Internet server component executes on the server computer Pages reside on the server and are sent to the browser for display Program logic is inserted through scripting languages, applets, or other controls

    24. Two-layer Architecture Primarily captures information from the user and updates the database The domain layer and data access layer are usually combined Input data is sent to a CGI or an application server The user-interface classes often contain the business logic and data access Processing takes place with servlets (Java) or code behind classes (.NET)

    26. Three-layer Architecture Separates domain layer and data access layers Necessary for systems with complex business logic or multiple user interfaces Using CGI Provide a use case controller for each form Using an application server Java tools: Java Server Pages and servlets .NET tools: Common Runtime Language and code behind classes

    28. Web Services A program that provides a service via the Internet The service is posted in a directory so that systems can find it Requests for information go to the UDDI directory UDDI provides the Internet address of a program offering that service The application then requests the information All communication is based on XML to allow for generic data exchange

More Related