Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Concepts like action state, acctivity diagram, class diagram, constructiing and object, generalization, interaction diagram, software degin, state diagram use case diagram are main topics. Implemtentation are done using Unified Modelling Languae. This lecture includes: Summary, Slide, Component, Diagram, Uml, Notation, Basic, Interfaces, Ports, Deployment
Typology: Summaries
1 / 15
This page cannot be seen from the preview
Don't miss anything!
UML 2 has also introduced another way to show a component's provided and required interfaces. This second way builds off the single rectangle, with the component's name in it, and places what the UML 2 specification calls interface symbols" connected to the outside of the rectangle.
In this second approach the interface symbols with a complete circle at their end represent an interface that the component provides -- this lollipop" symbol is shorthand for a realization relationship of an interface classifier. Interface symbols with only a half circle at their end (a.k.a. sockets) represent an interface that the component requires (in both cases, the interface's name is placed near the interface symbol itself). For example, the Order component provides two interfaces: OrderEntry and AccountPayable, and the Order component requires the Person interface.
Components may both provide and require interfaces. An interface is the definition of a collection of one or more methods, and zero or more attributes, ideally one that defines a cohesive set of behaviors. A provided interface is modeled using the lollipop notation and a required interface is modeled using the socket notation. A port is a feature of a classifier that specifies a distinct interaction point between the classifier and its environment. Ports are depicted as small squares on the sides of classifiers. Ports can be named, such as the Security and Data ports on the Student component. Ports can support unidirectional communication or bi-directional communication. The Student component implements three ports, two unidirectional ports and one bi-directional ports. The left-most port is an input port, the Security port is an output port, and the Data port is a bi-directional port.
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.
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.
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.
