Component Design and Implementation Diagrams

Design Diagrams Use Case Diagram can model the whole system but usually it models subsystem/component (relate actors to major functions) Activity Diagram is usually used to model the whole system or subsystem/component (it shows the sequence of major functions) Use case Detail is used to model a single function or service/component interface Class Diagram (discovered by analyzing the Usecase Detail and main business document) is used to model a subsystem / component static view Sequence/ Collaboration Diagram (is used to show the sequence of action between classes to perform a single function/ component interface State Diagram (usually done for the most critical object/component )

Implementation Diagrams Component Diagrams: The component diagram is one of the easier-to-understand diagrams, set of components and their relationships Illustrate static implementation view Component maps to one or more classes, Package Diagram: Organizing element to group Can group components Deployment Diagrams: Set of nodes and their relationships Illustrate static deployment view of architecture Node typically encloses one or more components

Review of Analysis and Design Methodologies Structural Approach (Context Diagram, DFD, Structural Chart, Structural English) Object Oriented Approach ( Use Case Diagram, Use Case detail, Activity diagram, Class diagram, Sequence diagram, Collaboration Diagram, Package diagram

Use-Case Diagrams Interaction of Users with System Components Actors External Entity that Interacts with Software Promote Simulation of Events Can be People, Software Tools, etc. Use-Case Diagram Graph of Actors and Set of Use Cases Enclosed by System (High-Level) or Class Boundary Black Box View of System Components Derived via User Interviews

Use-Case Diagrams Supermarket Example HTSS: System View HTSS Scan Items Ring Order Buy Items Customer Cashier Catalog Check Status Place Order Fill Order Estb. Credit Customer Sales Person Supervisor Catalog: Class View

Use-Case Diagrams Clinic

Activity Diagram -Granularity Level of Use-Cases is Variable © Makoto Nakayama, Ph.D. 8

Main Flow The customer selects the “find Product” Use Case Detail for the FindProduct Interface within a Store component (usually done for components that have User Interface, eg. OCX Main Flow The customer selects the “find Product” The customer selects the search criteria The Component returns a list of matching product Alternative flow 4-a if there is no product, the component will return no match string * customer can cancel at any time

Ways to identify and classes and class attributes and methods Use cases detail The Nouns in the Use Case Help Determine Class attributes The Verbs in the Use Case Help Determine Class Methods Major Business documents Major Business process

Getting classes form business document Order ( what is the most important Document

What entities are related to this document

Getting classes from Business process

Sequence Diagram for Supermarket component’s ordering interface

Collaboration Diagram Convey Same Info as Sequence Diagrams but Focus on Object Roles instead of messages Object Roles are Rectangles E.g., aHotel, aChain, etc.

Your Turn For eye glass store Create a use case diagram and a set of detail use-case descriptions for the process of buying glasses from the viewpoint of the patient, but do not bother to identify the flow of events within each use case. The first step is to see an eye doctor who will give you a prescription. Once you have a prescription, you go to a optical dispensary, where you select your frames and place the order for your glasses. Once the glasses have been made, you return to the store for a fitting and pay for the glasses. The store manger should be able to view daily and monthly reports © Makoto Nakayama, Ph.D. 26

Complete

Use Case Diagram Set Appointment View Appointment Dr Make Prescription Make Backorder View Appointment extend Make Order Dr Make Prescription include Make Production Order Staff extend View Reports Make Adjustment Order Manager Make completion notice Techn Process Payment

Componentized Use Case Diagram Appointment Set Appointment Make Backorder View Appointment Make Order Dr Make Prescription include Make Production Order Staff extend View Reports Make Adjustment Order Manager Make completion notice Techn Process Payment

Activity Diagram between components describing the major process sequence

Use Case Detail for Set Appointment Interface Main Flow Staff click on the appointment page Staff enter patient ID number Staff enter the Appointment date The system confirm the appointment Alternative flow 2-a If patient is new then the staff will enter patient details (name, address, ages,etc) 4-a if the date is reserved then a message will be shown and the system return to step 3 * Staff can cancel at any time

Class found in

Enter Staff Appointment

Enter Doctor Prescription Enter Staff Appointment

Enter Doctor Prescription View Enter Staff Appointment

Doctor Prescription Staff Appointment Order Enter View View Enter

Doctor Prescription Staff Appointment Order Enter View View Enter include Enter Order

Doctor Prescription Staff Appointment Order Product EF Lenses Enter View View Enter Staff Appointment include Enter Order include Product EF Lenses

Doctor Prescription Staff Appointment Technician Order Invoice Product Enter Doctor Prescription View View Enter Staff Appointment Technician Complete Enter Order Invoice Product EF Lenses (Status of the order) (Status of the order) (Status of the order)

Doctor Prescription Staff Appointment Technician Order Reports Manager Enter Doctor Prescription View View Enter Staff Appointment Technician Complete Enter Order Reports Manager Invoice View Product EF Lenses (Status of the order)

Componentizing class Doctor Prescription Staff Appointment Technician Enter Doctor Prescription View View Enter Staff Appointment Technician Complete Enter Order Reports Manager Invoice View Product EF Lenses Componentizing class

Use Case Detail for Set Appointment Interface Main Flow Staff click on the appointment page Staff enter patient ID number Staff enter the Appointment date The system confirm the appointment Alternative flow 2-a If patient is new then the staff will enter patient details (name, address, ages,etc) 4-a if the date is reserved then a message will be shown and the system return to step 3 * Staff can cancel at any time

Doctor Prescription Patient Staff Appointment Technician Order Reports Enter Doctor Prescription Patient View View Enter Staff Appointment Technician Complete Enter Order Reports Manager Invoice View Product EF Lenses

Sequence Diagram for Set Appointment interface Main Flow Staff click on the appointment page Staff enter patient ID number Staff enter the Appointment date The system confirm the appointment Alternative flow 2-a If patient is new then the staff will enter patient details (name, address, ages,etc) 4-a if the date is reserved then a message will be shown and the system return to step 3 * Staff can cancel at any time

Apontm Page <UI> patient Staff DB Click New Apt (Pat ID) Get Patent Info (Pat ID) Enter Date Return results Add appointment (Pat ID, date) Confirm Main Flow Staff click on the appointment page Staff enter patient ID number Staff enter the Appointment date The system confirm the appointment Now you update this diagram by adding the alternative flow elements

State Diagram (usually done for the most critical object) It should done for ORDER component Paid Prod ready Production Confirm Entered [ if item is missing] Wait Back order

First Assignment - “Your Turn you are a software engineer who met an agency who requires you to build a software application for their business (major process) Examples E book stores E money transfer E hotel reservation E course registration E Pizza order You can come with idea Note at least you need to have 4 classes or entity © Makoto Nakayama, Ph.D. 48

Use Smart Draw or Rational Rose or Visio for your drawing For this system, Define the business process steps Develop use case diagram. Draw an activity diagram for the main process. Draw a class Diagram Develop one use case detail Draw a sequence diagram for this case © Makoto Nakayama, Ph.D. 49

Component design principles. Description Acyclic Dependencies Allow no cycles in the dependencies graph between components. For example disallow A BC A because it includes a cycle. Common Closure The classes of a component should be closed together against the same kinds of changes. A change that affects a class within a component should not affect classes outside that component. In other words your components should be cohesive in that sweeping changes across several components are not required. Common Reuse The classes in a component are reused together. If you reuse one class in a component you reuse them all. This is another principle addressing cohesion. Dependency Inversion Abstractions should not depend on details, instead details should depend on abstractions. Open-Closed Software elements should be open for extension but closed for modification. Release-Reuse Equivalency The granule of reuse is the granule of release. In other words you should not reuse only part of a released software element. Stable Abstractions A component should be as abstract as it is stable. A component should be sufficiently abstract so that it can be extended without affecting its stability. Stable Dependencies Depend on the direction of stability – If component A depends on component B, then B should be more stable (e.g. less likely to change) than A. Creating Component Diagrams There are two fundamental strategies for developing a component model, either top down or bottom up. Given the choice I prefer the top-down approach because it provides a good mechanism for identifying the “software landscape” early in the project, something that is particularly important for teams comprised of several subteams because you want to work towards the same vision. Unfortunately a top-down approach suffers from the tendency to promote over-architecting, and hence over-building, of your system. For example Figure 1 calls out Security and Persistence components but you might not yet need anything even remotely that complicated. It would be a serious mistake to focus on building these two components instead of implementing actual business functionality that your stakeholders actually need. A second way to develop component models is from the bottom up. I’ll do this when we have an existing collection of classes that have been developed and we decide to componentize our design. Componentizing is often done to rescue reusable functionality out of an existing application or to split an application up so it can be easily dispersed between subteams. When I’m componentizing an existing object design I’ll often iterate through the following steps: Keep components cohesive. A component should implement a single, related set of functionality. This may be the user interface logic for a single user application, business classes comprising a large-scale domain concept, or technical classes representing a common infrastructure concept. Assign user interface classes to application components. User interface classes, those that implement screens, pages, or reports, as well as those that implement “glue logic” such as identifying which screen/page/… to display should be placed in components with the application stereotype. In Java these types of classes would include Java Server Pages (JSPs), servlets, and screen classes implemented via user interface class libraries such as Swing. Assign technical classes to infrastructure components. Technical classes, such as those that implement system-level services such as security, persistence, or middleware should be assigned to components which have the infrastructure stereotype. Define class contracts. A class contract is any method that directly responds to a message sent from other objects. For example, the contracts of the Seminar class likely include operations such as enrollStudent() and dropStudent(). For the purpose of identifying components, you can ignore all the operations that aren’t class contracts because they don’t contribute to communication between objects distributed in different components. Assign hierarchies to the same component. 99.9% of the time I find that it makes sense to assign all of the classes of a hierarchy, either an inheritance hierarchy or a composition hierarchy, to the same component. Identify domain components. A domain component is a set of classes that collaborate among themselves to support a cohesive set of contracts. The basic idea is that classes, and even other domain components, are able to send messages to domain components either to request information or to request an action be performed. On the outside, domain components appear simple, actually they appear like any other type of object but, on the inside, they are often quite complex because they encapsulate the behavior of several classes. A key goal is you want to organize your design into several components in such a way as to reduce the amount of information flowing between them. Any information passed between components, either in the form of messages or the objects that are returned as the result of a message send, represents potential traffic on your network (if the components are deployed to different nodes). Because you want to minimize network traffic to reduce the response time of your application, you want to design your domain components in such a way that most of the information flow occurs within the components and not between them. Identify the “collaboration type” of business classes. To determine which domain component a business class belongs to you need to analyze the collaborations it is involved with to determine its distribution type. A server class is one that receives messages, but doesn’t send them. A client class is one that sends messages, but doesn’t receive them. A client/server class is one that both sends and receives messages. Once you have identified the distribution type of each class, you are in a position to start identifying potential domain components. Server classes belong in their own component. Pure server classes belong in a domain component and often form their own domain components because they are the “last stop” for message flow within an application. Merge a component into its only client. If you have a domain component that is a server to only one other domain component, you may decide to combine the two components. Pure client classes don’t belong in domain components. Client classes don’t belong in a domain component because they only generate messages, they don’t receive them, whereas the purpose of a domain component is to respond to messages. Therefore, client classes have nothing to add to the functionality offered by a domain component and very likely belong in an application component instead. Highly coupled classes belong in the same component. When two classes collaborate frequently, this is an indication they should be in the same domain component to reduce the network traffic between the two classes. This is especially true when that interaction involves large objects, either passed as parameters or received as return values. By including them in the same domain component you reduce the potential network traffic between them. The basic idea is that highly coupled classes belong together. Minimize the size of the message flow between components. Client/server classes belong in a domain component, but there may be a choice as to which domain component they belong to. This is where you need to consider issues such as the information flow going into and out of the class. Communication within a component will often be simple message sends between objects in memory, communication between components may require an expensive marshalling effort in which a message and its parameters are converted to data, transmitted, and then converted back into a message again. Define component contracts. Each component will offer services to its clients, each such service is a component contract.

Component Interfaces Provides Requires interface component interface Requires interface defines the services that must be available for the component to operate correctly Provides interface defines the services that the component provides For example, the Order component provides two interfaces: OrderEntry and AccountPayable, and the Order component requires the Person interface. 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

Component Interfaces Provides Requires interface component interface DB Provides interface Requires interface component orderEntery.Customer orderEntery.date orderEntery.itemList orderEntery.Create orderEntery.Change e.g Button- up Design Method

Example of eye glass componentized Button- up Design Method Enter Doctor Prescription View View Enter Staff Appointment Technician Complete Enter Order Reports Manager Invoice View Product EF Lenses

Example of eye glass componentized Define Business Entities (fine-grained Business component) Enter Doctor Prescription √ View View Enter Staff Appointment √ Technician Complete Enter Order √ Reports √ Manager Invoice √ View Product √ EF Lenses

Example of eye glass componentized Define the most important interface

Example of eye glass componentized Define the required interface (sequential composition)

Apontm Page <UI> Using the sequence diagram (as dynamic view) for implementation of MakeAppt() interface Apontm Page <UI> Apont Staff DB Click New Apt (Pat ID) Get Patent Info (Pat ID) Enter Date Return results Add appointment (Pat ID, date) Confirm Main Flow Staff click on the appointment page Staff enter patient ID number Staff enter the Appointment date The system confirm the appointment

Apontm Page <UI> Using the sequence diagram (as static view) for implementation of MakeAppt() interface Enter Date Apontm Page <UI> Apont Staff New Apt

Example of eye glass componentized For more reusability, Define a coarse-grained Business Component

Example of eye glass componentized Define dependency

Sketch the components and interfaces corresponding to the given services Top- Down Method Flight Booking service Hotel Promotional Service Car Hire Promotional Service

Software Systems Requirements After you book a holiday, the company shall provide the holidaymaker with promotional services, which include Flight Booking, hotel deals and car rent promotional service at the destination and for the duration of her/his stay

Answer: Flight Booking Provides Requires Flight Booking Flight Information Customer Preference Information Customer data

Promotional Hotel Booking Service.. Provides Requires Promotional Hotel Booking Service List of available Hotels Flight Information Customer Preference Information

You can even provide more services.. Provides Requires Promotional Hotel Booking Service List of available Hotels List of Budget Hotel List of Five stars List of 4 stars List of 3 stars Flight Information Customer Preference Information

Car Hire Promotional Service Provides Requires Car Hire Promotional Service List of available Car agents Flight Information Customer Preference Information List of cars deals

Gluing the Components Provides Requires Provides Requires Flight Car Hire Promotional Service List of available Car agents Flight Information Customer Preference cars deals Provides Requires Flight Booking Flight Information Customer Preference Information data Provides Requires Promotional Hotel Booking Service List of available Hotels List of Budget List of Five star List of B&B List of 3 stars Flight Information Customer Preference

Another way of simplified example of binding holiday reservation system

Component Diagram (Adding Actors) - Example

Example Store's component inner structure composition.

Component Diagram Guidelines Use Descriptive Names for Components Use Environment-Specific Naming Conventions for Detailed Design Components Apply Textual Stereotypes to Components Consistently Delay Modeling Data and User Interface Components • Interfaces Prefer Lollipop Notation To Indicate Realization of Interfaces By Components Prefer the Left-Hand Side of A Component for Interface Lollipops Show Only Relevant Interfaces • Dependencies and Inheritance Model Dependencies From Left To Right Place Child Components Below Parent Components Components Should Only Depend on Interfaces (no direct calls between components objects)

Basic Notation Used in Component Diagrams When drawing a component on a diagram, it is important that you always include the component stereotype text (the word "component" inside double angle brackets, as shown in Figure below) and/or icon. The reason? In UML, a rectangle without any stereotype classifier is interpreted as a class element. Creating Component Diagrams There are two fundamental strategies for developing a component model, either top down or bottom up.  Given the choice I prefer the top-down approach because it provides a good mechanism for identifying the “software landscape” early in the project, something that is particularly important for teams comprised of several subteams because you want to work towards the same vision.  Unfortunately a top-down approach suffers from the tendency to promote over-architecting, and hence over-building, of your system.  For example Figure 1 calls out Security and Persistence components but you might not yet need anything even remotely that complicated.  It would be a serious mistake to focus on building these two components instead of implementing actual business functionality that your stakeholders actually need.  A second way to develop component models is from the bottom up.  I’ll do this when we have an existing collection of classes that have been developed and we decide to componentize our design.  Componentizing is often done to rescue reusable functionality out of an existing application or to split an application up so it can be easily dispersed between subteams.   When I’m componentizing an existing object design I’ll often iterate through the following steps: Keep components cohesive.  A component should implement a single, related set of functionality.  This may be the user interface logic for a single user application, business classes comprising a large-scale domain concept, or technical classes representing a common infrastructure concept. Assign user interface classes to application components.  User interface classes, those that implement screens, pages, or reports, as well as those that implement “glue logic” such as identifying which screen/page/… to display should be placed in components with the application stereotype.  In Java these types of classes would include Java Server Pages (JSPs), servlets, and screen classes implemented via user interface class libraries such as Swing. Assign technical classes to infrastructure components.  Technical classes, such as those that implement system-level services such as security, persistence, or middleware should be assigned to components which have the infrastructure stereotype. Define class contracts.  A class contract is any method that directly responds to a message sent from other objects.  For example, the contracts of the Seminar class likely include operations such as enrollStudent() and dropStudent(). For the purpose of identifying components, you can ignore all the operations that aren’t class contracts because they don’t contribute to communication between objects distributed in different components. Assign hierarchies to the same component.  99.9% of the time I find that it makes sense to assign all of the classes of a hierarchy, either an inheritance hierarchy or a composition hierarchy, to the same component.  Identify domain components. A domain component is a set of classes that collaborate among themselves to support a cohesive set of contracts. The basic idea is that classes, and even other domain components, are able to send messages to domain components either to request information or to request an action be performed. On the outside, domain components appear simple, actually they appear like any other type of object but, on the inside, they are often quite complex because they encapsulate the behavior of several classes.  A key goal is you want to organize your design into several components in such a way as to reduce the amount of information flowing between them. Any information passed between components, either in the form of messages or the objects that are returned as the result of a message send, represents potential traffic on your network (if the components are deployed to different nodes). Because you want to minimize network traffic to reduce the response time of your application, you want to design your domain components in such a way that most of the information flow occurs within the components and not between them. Identify the “collaboration type” of business classes.  To determine which domain component a business class belongs to you need to analyze the collaborations it is involved with to determine its distribution type. A server class is one that receives messages, but doesn’t send them. A client class is one that sends messages, but doesn’t receive them. A client/server class is one that both sends and receives messages.  Once you have identified the distribution type of each class, you are in a position to start identifying potential domain components. Server classes belong in their own component. Pure server classes belong in a domain component and often form their own domain components because they are the “last stop” for message flow within an application. Merge a component into its only client. If you have a domain component that is a server to only one other domain component, you may decide to combine the two components.    Pure client classes don’t belong in domain components. Client classes don’t belong in a domain component because they only generate messages, they don’t receive them, whereas the purpose of a domain component is to respond to messages. Therefore, client classes have nothing to add to the functionality offered by a domain component and very likely belong in an application component instead. Highly coupled classes belong in the same component. When two classes collaborate frequently, this is an indication they should be in the same domain component to reduce the network traffic between the two classes. This is especially true when that interaction involves large objects, either passed as parameters or received as return values. By including them in the same domain component you reduce the potential network traffic between them. The basic idea is that highly coupled classes belong together. Minimize the size of the message flow between components. Client/server classes belong in a domain component, but there may be a choice as to which domain component they belong to. This is where you need to consider issues such as the information flow going into and out of the class.  Communication within a component will often be simple message sends between objects in memory, communication between components may require an expensive marshalling effort in which a message and its parameters are converted to data, transmitted, and then converted back into a message again. Define component contracts.  Each component will offer services to its clients, each such service is a component contract.

Stereotypes <<UI>>: – A “front-end” of your system, such as the collection of HTML pages and ASP/JSPs that work with them for a browser-based system or the collection of screens and controller classes for a GUI-based system. <<database>>: – A hierarchical, relational, object-relational, network, or object-oriented database. <<page>>: – HTML page.

Stereotypes <<executable>>: – A software component that can be executed on a node. • <<file>>: – A data file. • <<infrastructure>>: – A technical component within your system such as a service Security, Persistence or an audit logger. • <<library>>: – An object or function library.

Stereotypes <<source code>> : – A source code file, such as a .java file or a .cpp file. • <<table>>: – A data table within a database. • <<web service>> – One or more web services. • <<XML DTD>> – An XML DTD

Component Diagram - Example

Component Diagram Example in UML 2

Packages Packages Contain Multiple components and are Associated and Linked to One Another Dependency Arrow is Dashed Indicates that One Package Depends on Another

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 important components/packages of the system will physically run and how they will communicate with each other. 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.

Steps of modeling Identify nodes that represent system’s client and server processors Highlight those devices that are essential to the behavior E.g.: special devices (credit card readers, badge readers, special display devices) Use stereotyping to visually distinguish Model Only Vital Software Components/ packages Indicate Communication Protocols Via Stereotypes Model Only Critical Dependencies Between Components

Example : Deployment Diagram

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,

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

Communication Protocols Stereotypes • <<Asynchronous>>: – An asynchronous connection, perhaps via a message bus or message queue. • <<HTTP>>: – HyperText Transport Protocol, an Internet protocol. • <<JDBC>>: – Java Database Connectivity, a Java API for database access. • <<ODBC>>: – Open Database Connectivity, a Microsoft API for database access.

• <<RMI>>: – Remote Method Invocation, a Java communication protocol. • <<RPC>>: – Communication via remote procedure calls. • <<Synchronous>>: – A synchronous connect where the senders waits for a response from the receiver. • <<web services>>: – Communication is via Web Services protocols such as Simple Object Access Protocol (SOAP) and Universal Description, Discovery, and Integration (UDDI) used for building service registry centers

Network Diagrams Network diagrams are often drawn using software-based drawing tools (figure below was drawn using Microsoft Visio)

Example : Rational Rose Component Tool

Example : Rational Rose Deployment Tool

Assignment 2 5 mark- Use Smart Draw or Rational Rose or Visio for your drawing For the previous assignment Draw Structural chart (system, subsystem, component) Draw a component diagram 1user interface components (e.g. calculator, Calendar, currency exchanger, etc)+ At least three business components 1 Database Component 1security or persistence Components use stereotypes Draw the package diagram for that domain Draw deployment diagrams for this system (important component / packages+ client +servers + web services + communication protocol stereotype) Identify the reusable component (you might change their names)