UML Diagrams Full Course (Unified Modeling Language)

almost all software developers should have some understanding of uml uml is a way to use diagrams to visualize a system or database it's used frequently in software development to plan out software systems this introduction to uml is from ava coders and welcome to the uml course for beginners we'll look into the most widely used diagrams they're basic notation and applications each diagram that we will study in this course will be supported with a practical example of a system or a situation that can be modeled with its help i like to start this course with a little introduction to uml and a brief overview of each diagram how does it look like and what is it actually used for first of all uml stands for unified modeling language which according to the legend was developed when some serious it people were fed up with an ambiguous variety of circles dashes stars and clouds uml 2.0 that we're going to study in this course consists of an integrated set of diagrams of various agreed shapes and forms designed to help system and software developers to define design visualize and document software system artifacts and in some cases some business models uml is a set of best engineering practices that has proven to be effective in modeling large and complex systems and is a very important part of object-oriented software development uml mainly uses graphical notation to express the software project's design uml helps teams to communicate explore potential designs and validate software architectural designs the purpose of uml is to provide a standardized annotation that can be used by all object-oriented methods as well as selecting and integrating best elements of the precursor notations uml has been designed for a wide range of applications hence it provides constructs for a wide variety of systems and activities for example distributed systems analysis system design and deployment uml diagrams can be divided into two main types structure diagrams and behavior diagrams there are seven types of structure diagrams composite structure diagram deployment diagram package diagram profile diagram class diagram object diagram and component diagram behavior diagrams include activity diagram use case diagram state diagram sequence diagram communication diagram interaction overview diagram and timing diagram now a few words about each one of them class diagram is this central modeling technique that is used in almost all object oriented methods this diagram describes the types of objects in the system and different kinds of static relationships that exist between them the three most important types of relationships in class diagrams but there are actually more of them are association which represents relationships between instances of types for example a person works for a company or a company has multiple offices inheritance which corresponds directly to inheritance in object oriented design and aggregation which is a form of object composition in object oriented design component diagrams illustrate how components are put together to form larger components or software systems and illustrates the architecture of software components and dependencies between them these software components can include runtime components executable components and source code components deployment diagram helps to model the physical aspect of an object-oriented software system this is a block diagram that shows the system architecture as deployment or distribution of software artifacts artifacts represent specific elements in the physical world that are the result of the development process the diagram simulates the runtime configuration in a static view and visualize the distribution of artifacts in the application in most cases this involves simulating hardware configurations along with the software components that host them object diagram is an instance of the class diagram it shows a detailed snapshot of the system state at a particular point in time the difference is that the class diagram is an abstract model of classes and their relationships however the object diagram represents an instance at a specific moment which is concrete in nature the use of object diagrams is rather limited namely to show examples of data structures package diagram is a structural diagram that shows packages and dependencies between them it allows us to display different views of the system for example it is easy to simulate a layered application composite structure diagram is similar to the class diagram and it is a kind of a component diagram used mainly in micro level system modeling but it depicts individual parts instead of whole classes this is a type of static structure diagram that shows the internal structure of a class and interactions that the structure makes possible this diagram can include internal parts ports through which the parts can communicate with each other or through which the class instances can communicate with various parts and with the outside world as well as connectors between parts and ports composite structure diagram is a set of interrelated elements that interact at runtime to achieve a specific goal each element has a dedicated role in this collaboration profile diagram allows us to create domain and platform specific stereotypes and define relationships between them we can create stereotypes by drawing shapes of stereotypes and linking them to composition or generalization through a resource oriented interface we can also define and visualize stereotype values use case diagram describes the functional requirements of a system in terms of use cases in essence it is a model of intended functionality of the system use cases and its environment actors use cases allow us to link what we need from the system with how the system meets those needs activity diagrams are graphical representations of workflows of stepwise activities and actions with the support of choice iteration and concurrency they describe the control flow of the target system such as exploring complex business rules and operations as well as describing the use cases and business processes in uml activity diagrams are meant for modeling both computational and organizational processes state machine diagram is a type of diagram used in uml to describe system behavior which is based on david harrell's concept of state diagrams state machine diagrams depict permitted states and transitions as well as events that affect those transitions this diagram helps to visualize the entire life cycle of objects and thus helps to better understand state-based systems sequence diagram models the interaction of object based on a time sequence it shows how objects interact with each other in a particular use case similar to sequence diagram the communication diagram is also used to model the dynamic behavior of a use case when compared to sequence diagram communication diagram focuses more on showing object collaborations rather than the time sequence in fact communication diagrams and sequence diagrams are semantically equivalent and one can be generated from another interaction overview diagram focuses on the overview of the flow of control of the interactions this is a variant of activity diagram where the nodes depicted are the interactions or interaction occurrences interaction overview diagram describes interactions in which messages and lifelines are hidden we can link up the real diagrams and achieve a high degree of navigation between diagrams within an interaction of your diagram timing diagram shows the behavior of the object or objects at a given time period in fact this is a special form of a sequence diagram and the differences between them are that the axes are swapped so that the time increases from left to right and the lifelines are displayed in separate compartments arranged vertically so why are there so many diagrams the reason for this is that this can help to examine the system at different angles and there can be many participants involved in software development for example analysts architectures coders testers quality control customers technical authors these people are all interested in different aspects of the system and each requires a different level of details for example a coder would want to understand the design of the system to be able later to convert this design into some low-level code in contrast a technical writer is interested in the behavior of the system as a whole and would want to understand the product's features uml tries to be a language that all those participants can benefit from and possibly use at least one of its diagrams uml class diagram illustrates the structure of the system by describing classes their attributes methods and relationships between them just before we begin discussing the diagram let's remind ourselves what is a class in a nutshell class is a template for creating objects as well as representing objects initial state attributes and behavior methods each attribute has its own type each method has its own signature but in the class diagram only the class name is mandatory and it makes sense because even the best psychics will not be able to guess what this nameless square supposed to mean or what it generally refers to so let's take a look at the building blocks of a class diagram starting with the class itself the name of the class is written in the uppermost partition followed by the class attributes with their types written after the column and finally the last partition contains methods the type that the method can return is written after the column in the method signature you've probably noticed the minuses and pluses before the class attributes and methods these are the access modifiers or class visibility notation plus means public miners private hash protected and tilde means package local each parameter in a method can also be described in terms of its direction with the respect to the caller in out in out for example method 1 uses p1 as an input parameter and the value of p1 is somehow used by the method and the method does not change p1 method 2 accepts p2 as an input output parameter the p2 value is somehow used by the method and it accepts the output value of the method and the method itself can change p2 method 3 uses p3 as the output parameter in other words the parameter serves as a repository for the output value of the method we can use class diagrams at different stages of the software development lifecycle therefore we might want them to reflect a different levels of specification and thankfully there are three different perspectives or levels of specification that we can use a conceptual perspective is when class diagrams are interpreted as describing entities of the real world thus if we choose conceptual perspective we construct a diagram that represents the concepts in the domain these concepts relate to classes that implement them the conceptual perspective is considered language independent a specification perspective is when diagrams are interpreted as describing abstractions of software or components with specification and interfaces but without any reference to a specific implementation thus if you look at the specification perspective you can generally see some software interfaces but not necessarily their implementation and finally the implementation perspective is when diagrams are interpreted as a description of software implementations in a particular technology or programming language thus if you choose to use this perspective you can choose to depict the actual software implementation now let's have a look at the relationships between classes i will describe the six main types of notation that are most common these are association inheritance implementation dependency aggregation and composition similar to relationships connecting objects associations connect classes in order for there to be a connection between classes there must be an association between them if we assume that we have two classes that interact with each other a continuous connecting line should be drawn between them indicating the association in the diagram often we can also see a verb written above the line that conveys its meaning in addition we can also specify the multiplicity that is the number of objects that can take part in the relationship multiplicity is specified as a comma separated list of intervals where each interval is represented as a minimum maximum for example one student can learn from many tutors and a tutor can teach many students inheritance sometimes it is also called generalization as the name implies this is a schematic representation of the relationship between the parent class and its descendants the hollow arrow is always directed towards the parent class a classic example of inheritance depicts a square class a rectangle class and a circle class as descendants of their common parent class we can connect each class with their parent class separately or combine those lines and draw one common arrow line that connects all common descendants with their parent if the sentence inherits from an abstract class then the name of such parent class is written in italics realization usually this refers to the relationships between an interface and objects that implement this interface for example the owner interface has methods for buying and selling private property and the relationships between the owner interface and the person and corporation classes that implement this interface are depicted by a dashed line with an arrowhead pointing at the interface dependency when an object one class uses an object of another class in its method and this object is not stored in any field then this kind of relationship is modeled as a dependency dependency is essentially a special case of the association of two classes in this case changes in one class will inexorably entail changes in the other for example this person class has a has read method with a book as an input parameter which returns true if for example the person has read the book dependency is drawn with a dashed line with arrowhead pointing towards the class on which the method of another class could depend aggregation a special type of relationship between classes when one class is a composite part of another for example a programmer's workstation could consist of a chair a desk a computer and a fan but when we delete the workstation class we still have all these classes but on their own they no longer form an aggregate class workstation aggregation is shown as a continuous align with an unfilled diamond connected to the class which represents the aggregate composition is a type of aggregation but this time classes that form the aggregator class are destroyed when the aggregator class is destroyed for example our body is made up of organs but they can't function by themselves composition is depicted similarly to aggregation but this time the diamond is solid and as a conclusion to this topic i just want to remind you that uml is not so much about a pretty picture uml is actually a powerful tool in the programmer's toolkit if you can understand and utilize it properly say get in the habit of drawing your class diagram before you sit down and actually code your next e-commerce gaming financial and whatnot project time invested in drawing as a synth and clear uml diagram will eventually pay off and can save your project from design flows and other errors you might encounter without a proper plan in front of you uml component diagrams are used for modeling physical aspects of object oriented systems that are used for visualizing defining and documenting component-based systems as well as construction executable systems using forward and reverse engineering component diagrams are essentially class diagrams that focus on system components that are often used to model the static implementation view of a system component diagram breaks down the system under development into various high levels of functionality each component is responsible for one clear goal within the entire system and interacts with other essential elements only on a need to know basis so how does it work data for example account and inspection id flows into the component through the port on the right and gets converted to a format that internal components can utilize interfaces on the right are known as required interfaces they represent the services the component needs to fulfill its responsibilities data then passes through various connections and other components before it is output through the ports on the left those interfaces on the left are also known as provided interfaces and other components of the system can interact with them in order to take advantage of the output results of the component it is important to note that the internal components are surrounded by a large box which can represent the system as a whole in that case there will be no component symbol in the upper right corner or a subsystem or component of the overall system in this case the box itself is a component a component is a modular part of a system that encapsulates its content in uml 2.0 a component is drawn as a rectangle with optional compartments arranged vertically the following example shows two types of interface components provided interface is drawn with a complete circle at its end and represents the interface that the component provides to the system this symbol is known by the nickname lollipop and is a shorthand for a realization relationship of an interface classifier required interface is indicated by a semicircle at the end and as you might guess it indicates the interface that the component needs to perform a task in both cases the interface's name is placed next to the interface symbol subsystem classifier is a special kind of a component classifier because of this the subsystem notation element inherits the same rules as the componentation element the only difference is that the subsystem element is marked with the keyword subsystem instead of the keyword component ports are depicted with a square drawn along the edge of the system or a component a port is mainly used to expose required and provided component interfaces graphically a component diagram resembles a system of components and logical nodes connecting them in general some relationships might already be familiar to you as they are widely used in the class diagram but there are some unique ones association an association defines the semantic relationship that can occur between typed instances it is drawn as a straight line connecting two or more components of the system composition composite aggregation is a strong form of aggregation that requires a part instance to be included in at most one composite at a time if a composite is deleted all its parts are usually deleted with it aggregation very similar to composition but in this case the child component can exist on its own even without being a part of the aggregator class aggregation is drawn with a hollow diamond pointing towards the aggregator constraint a condition or restriction expressed as a text in a natural language or in a machine-readable language in order to declare some of the semantics of an element dependency dependency is a relationship where an element or set of elements require other elements for their specification or implementation this means that the full semantics of the dependent elements are either semantically or structurally dependent on the definition of the supplier element or elements inheritance inheritance or generalization is a taxonomic relationship between a more general classifier and a more specific classifier each instance of a specific classifier is also an indirect instance of the general classifier thus the specific classifier inherits the features of the more general classifier let's have a look at some use cases consider a typical step-by-step process of modeling a source code that shows how we would approach creating a component diagram for a program first of all with the help of forward or reverse engineering we determine the set of source code files of interest and model them as components for larger systems we can use entire packages to display groups of files don't forget about tags that indicate the version of the source code file in use you can also specify its author or the date and time of the last change we can also model the compilation dependencies between these files using dependencies and now let's have a look at a step-by-step process for modeling an executable release first we define a set of components that we want to model typically this will include some or even all components that are on a single node or a distributed system of these sets of components across all nodes in the model it's worth considering the type of each component in this set for most systems there is only a small number of different kinds of components such as executable files libraries tables other files and documents we can also use uml extensibility mechanisms to provide visual cues for these types it is important not to forget to consider the relationship of each element in the system with its neighbors most often this will be associated with interfaces that are exported or realized by certain components and then imported or used by others but if we want our model to be at a higher level of abstraction then we can exclude these intermediate interfaces that hold such relations together showing only dependencies among the components themselves and finally in modeling a physical database first we identify the classes that will represent our logical database schema then we choose a mapping strategy for mapping these classes to tables it is also worth taking into account the physical distribution of our database because the mapping strategy will also be affected by the location in which you want to store data after the databases deployment to visualize define build and document our mapping we need to create a component diagram that will contain these components as tables uml deployment diagram illustrates the configuration of runtime processing nodes and the components that live on them deployment diagram is a kind of a structural diagram used in modeling the physical aspects of an object-oriented system they're often used to simulate a static representation of a system deployment for example topology of the hardware deployment diagrams show the structure of the runtime system they model the elements of physical hardware and the ways of communicating between them they can be used to plan a system architecture they can also be useful for documenting the deployment of software components or nodes these diagrams are important for visualizing defining and documenting embedded client server and distributed systems as well as managing runtime systems through forward or reverse engineering a deployment diagram is just a special kind of a class diagram that focuses on system nodes graphically deployment diagram looks like a collection of vertices and arcs deployment diagrams usually contain the following notation a 3d box represents a node either software or hardware hardware node may be marked with a stereotype notation connections between nodes are represented with a line with optional stereotype notation nodes can reside within other nodes the diagram can also reflect dependencies associations as well as nodes or restrictions these are the steps that are normally taken to model an embedded system identify devices and nodes that are unique to your system provide visual cues especially for unusual devices using uml extensibility mechanisms to identify system stereotypes with matching icons you will also want to distinguish between processes that contain software components and devices that at this level of abstraction do not directly contain software model the relationships between these processors and devices in a deployment diagram similarly specify the relationships between the components in the implementation view of your system and the nodes in the deployment view of your system if necessary expand the capabilities of any smart devices by modeling their structure with a more detailed deployment scheme here are the steps for modeling a client server system identify the nodes that represent the client and server processors of your system highlight those devices that are related to the behavior of your system for example you can simulate special devices such as credit card readers icon readers and display devices other than monitors since placement of the latter in the systems hardware topology is likely to be of a great architectural importance provide a visual cues for these processors and devices through stereotyping model the topology of these nodes in the deployment diagram similarly specify the relationships between the components in the implementation view of your system and the nodes in the deployment view of your system and here are the steps you will need to take when modeling a distributed system identify the devices and processors of the system as for simpler client server systems if you need to reason about the network performance or the impact of changes on this network be sure to simulate communication devices at a level of detail that is sufficient to conduct these estimates pay particular attention to logical groups of nodes that you can specify with packages where possible use tools that discover the topology of your system by walking your system's network if you need to focus on the dynamics of your system use the use case diagram to indicate the types of behavior you're interested in and expand these use cases with interaction diagrams when modeling a fully distributed system it is common to transform or represent the network itself as a node that is the internet lan or one might be depicted as nodes in the form of a single box rather than a combination of elements when you develop a deployment plan for your company you might discover that you don't know where to start and what to focus on the following checklist can give you some ideas for planning your deployment how will your system be installed who will install it how long will it take where the installation can possibly fail how long can it take to install your system what backups do you need before the installation will data conversion be necessary how did you know that the installation was successful if different versions of the system work simultaneously how will you resolve the conflicts what physical sites do you need to deploy and in what order how will you train your support and operational staff will it be necessary to deploy a production support system so that support staff will use their own environment to model problems how will you train your users what documentation and in what formats and languages do your users as well as support team and operation specialists need how will documentation updates be deployed what existing system should the new system interact with or integrate how reliable should the system be will any additional equipment be required in the event of a system failure what or who will connect or interact with the system and how will they do it what software including the operating systems and communication protocols will the system use what hardware and software will users interact directly with pcs network computers browsers etc how will you control the system after deployment how secure should the system be does it needs a firewall physically safe equipment etc answering these questions will save you a lot of time in the future and protect you and your team from unpleasant surprises during and after the deployment of the system uml object diagram is an instance of a class diagram it captures a snapshot of the detailed state of the system objects and their relationship at a specific point in time it can be considered as a special case of a class diagram or a communication diagram the use of the object diagrams is quite limited and mainly comes down to demonstrating examples of data structures during the project analysis phase you can create a class diagram to describe the structure of the system and then create a set of object diagrams as test cases to verify the accuracy and completeness of the class diagram prior to creating a class diagram you can create an object diagram to find out facts about specific model elements and their relationships or to illustrate specific examples of the required classifiers the object diagram illustrates the relation between the instantiated classes and the defined class as well as the relationship between the objects in the model system at a fixed point in time it's fair to say that it's a snapshot of your system at a certain point in time which will depict system objects in a certain state which will directly represent real instances and prototypes these diagrams are useful for example when you want to depict a small part of a large system in which case the use of a class diagram would be an overkill as well as in case you want to model recursive relationships or to study the behavior of a system at a particular moment in time the best way to show what an object diagram looks like is to show an object diagram derived from the corresponding class diagram this humble class diagram illustrates a simple example in which a department depicted consisting of many other departments and this object diagram is nothing more than a detailed representation of the previous class diagram with examples and links let's walk through the basic notation of an object diagram each object is drawn as a rectangle the name of the object and its class are usually underlined and separated with a column the name of the object is on the left the name of the class is on the right the attributes of an object are listed in a separate compartment under the name of the class or object and must indicate the values assigned to them links in general are varieties of associations between classes and are discussed in detail in the video about class diagrams since uml object diagrams provide a snapshot of instances and the relationships between them in the system we can create object diagrams by instantiating the model elements on class diagrams deployment diagrams components and use case diagrams for example we can represent a part of the company's structure with the object diagram a communication diagram without any messages can also be called an object diagram and relationships between objects can be called links an object diagram must be a valid instance of a static class diagram objects must have classes and relationships between objects must be the instances of associations between classes that is relationships between objects will essentially be similar to relationships between classes let's look at some steps for modeling object structures first of all define the mechanism that you would like to model this mechanism can represent some function or behavior of the part of the system that you are modeling which is basically the result of the interactions between classes interfaces and other elements therefore it is necessary to identify the classes interfaces and elements for each mechanism that participate in this model and determine the relationships between them after that consider for example one scenario that walks through this mechanism and at a certain point in time renders each object that participates in the mechanism expand the state and attribute values of each such object to understand this scenario a kind of analogy would be the mechanical clocks imagine it is noon and we pretend to freeze the time to examine the elements of the mechanism what do they do what do the hour and minute hands point to which gears and sprockets are involved and so on let's have a look at another example robot moving behavior here one object represents the robot itself r is an instance of a robot and r is currently in a state marked moving this object has a link to w an instance of the world which is an abstraction of a model of the world for the robot this object is linked with several objects consisting of instances of the element that represents entities that the robot has identified but has not yet assigned in its world view these elements are marked as part of the global state of the robot currently w is associated with two instances of area one of them a2 is shown with its own links to the three wall objects and one door object each of these walls has an attribute width and each wall is linked with neighboring walls by and large this diagram graphically shows how the robot recognizes this enclosed area which has walls on three sides and a door on the fourth the next example is deriving an object structure similar to communication diagram in addition to displaying the state of objects at a certain point in time an object diagram can also be used for example to represent the occurrences of interactions between classes during the runtime uml package diagram is a kind of a structural diagram that shows the location and organization of model elements in a medium scale and large scale projects a package diagram can display both this structure and the dependencies between subsystems or modules illustrating various kinds of systems such as a layered application for example if the system is of a significant size it should be divided into smaller subsystems each with its own class diagram in uml notation these partitions or subsystems are called packages a package is a group of elements of the model and it can also be used in other uml diagrams packages themselves can be nested in other packages which is basically a uml version of folders package diagrams are usually used when it is necessary to group a related uml elements and determine the scope of their names or when you need to provide a way to visualize dependencies between parts of the system as well as to provide some support for analysis or determine the compilation order package diagrams are used to structure high-level system elements when modeling a package diagram you should bear in mind that a package is a uml mechanism for grouping elements including other packages each package has its own namespace in which all names must be unique each model element belongs to a single package packages form a hierarchy packages are displayed as rectangles with small tabs at the top package's name is normally written on its tab or dedicated rectangle namespace dotted lines with arrows depict dependencies one package is said to be dependent on other if changes in that other package can cause changes in the first one as well a system could be depicted in the form of a package with the stereotype system and it represents all the elements of the model that are relevant to a particular project you can also break the system apart into business systems and application systems when creating more detailed models to make them smaller but more efficient package diagram can also display the logical architecture of a system a subsystem is a group of model elements that are part of some larger system since the system or subsystem is a stereotypical package it has all the properties of the package and it also follows the rules of the package and all those model elements that are contained inside the system or the subsystem will also belong to the package and follow the same rules now what does this word stereotype actually mean stereotype is a high-level classification of an object that gives some idea of what the object is classes can be grouped by stereotypes their names are written inside the angle brackets above the class name stereotype allows us to extend uml to fit our modeling needs more specifically in other words stereotyping a uml element makes it act as something that has specific properties elements in packages may also have different visibility of elements of other packages and this also needs to be taken into account during the process of modeling of a system elements of a package with public visibility are available outside the package while elements with private visibility are available only for other elements within the package in uml public protected and private visibilities correspond to a class that is a public protected or private a public element is visible to all elements that can access the content of the namespace to which it belongs public visibility is represented by the plus sign a protected element is visible to elements related to generalization relationship to the namespace that owns it protected visibility is represented by the hash sign a package element is owned by a namespace that is not a package and is visible to all elements that are in the same package package visibility is marked by a tilde a private element is visible only inside the namespace that owns it private visibility is represented by the minus sign let's look at the types of dependency relationships represented by the stereotypes the element in the client package uses the public element in the supplier package the client depends on the supplier if the package dependency is shown without a stereotype then it should be marked with a use stereotype public elements of the supplier namespace are added as public elements to the client namespace elements in the client's namespace can access all public elements in the supplier namespace using unqualified names public supplier namespace elements are added as private elements to the client namespace elements in the client namespace can access all public elements in the supplier namespace using unqualified names trace normally represents a historical development of one element into another more developed version usually this is the relationship between models not elements public elements of the supplier package are combined emerge with the client package elements the dependency is used only in meta modeling and the chance of encountering it in the modern object-oriented analysis and design is even less than encountering an elephant in the central london next we will analyze an example diagram of the order tracking scenario for an online store in this diagram the track order module is responsible for providing tracking information for product ordered by our customers the types of customers are encrypted inside the tracking number truck order module refers to the system and updates the current delivery status for the customer based on the description of the project first we must determine what packages will be present in the system and figure out the relationships between them so how to determine which packages do we need to model the system suppose that we have a module that tracks an order it could be some sort of a tracking module and in order to perform its duty it must communicate with another module in order to figure out the details of the order let's call this module order details after receiving the details of the order it needs to know the shipping details so let's introduce a shipping module and now let's determine the dependencies between them the track order module must receive the order details from the order details module in response order details module requires to know the information provided by the client two modules communicate with each other which provides the access dual dependency to learn the shipping information the shipping module can import the truck order module to make the navigation easier finally the truck order is dependent on the ui framework and this completes our order processing subsystem design composite structure diagram contains classes interfaces packages and their relationships and it provides a logical representation of a software system or its part this diagram is one of the new artifacts added in uml 2.0 and it shows the internal structure including parts and connectors of a structured classifier or collaboration the composite structure diagram plays a role similar to the class diagram but allows you to delve into details of the internal structure of multiple classes and show the interactions between them you can graphically represent inner classes and parts and show associations both between classes and within them in other words composite structure diagrams show the internal parts of a class the part's name is usually constructed with part's name then colon then parts type with multiplicity stated inside the square brackets aggregated classes are parts of a class but parts are not necessarily classes a part is any element that is used to make up the containing class suppose we are modeling a system for an online store in which customers can join a loyalty program that provides them with some benefits discounted shipping for example in order to allow such a feature we expanded the customer object so now we have a regular customer and a member of our loyalty program let's start by simulating an online store using a class diagram we have a class 4 item which can be aggregated by the order class which is composed by the customer class which itself is composed by the store manager class we have many objects that end up within other objects on the diagram everything looks as if it ends up inside the store manager so we can create a composite structure diagram to clearly demonstrate what this manager consists of composite structure diagram shows us a clear picture of the store manager from its own point of view instead of this system as a whole store manager directly contains two types of objects customer and item as indicated by the two composition arrows in the class diagram the composite structure diagram here shows the inclusion of customer subtypes explicitly please note that the type of both parts is declared as customer because the store treats both objects as customer objects we also see a connector that shows the relationship between item and order order is not contained directly in the store manager class but we can show relationships with parts nested in the object that it aggregates the question is do these two diagrams essentially describe the same thing or have the same meaning well in the class diagram the relationship between the description and pricing is ambiguous strictly speaking they are not exactly the same the class diagram shows that description will have a reference to the pricing object but this does not specify whether the link between the two objects is contained inside the item explicitly if we use a composite structure diagram the relationship between the description and pricing objects becomes obvious specific implementations of an object's activity can be clearly modeled composite structure diagrams are good for describing aggregation but in this case models will also need to contain references to objects outside the class that we are modeling references to external objects are shown with a dashed rectangle even if they refer to an object outside the class the link itself is inside the model class and it is an important step in demonstrating its implementation the key object of composite structure specified in the uml 2.0 are structured classifiers parts ports connectors and collaborations collaboration describes the structure of collaborating parts and their roles in the interaction and is used when we want to determine only those roles and connections that are necessary to achieve a specific goal of such collaboration for example the purpose of a collaboration may be to define the roles of components of a classifier having identified the main roles the collaboration simplifies the structure and clarifies the behavior of elements in the model itself in this example the wheels and the engine are parts of the collaboration and front axle and rear axle are connectors a car is a composite structure that shows parts and connections between parts a part is a diagram element that represents a set of one or more instances owned by a structured classifier a part describes the role of the instance in the classifier we can create parts in the structure compartment of the classifier and in several uml diagrams such as composite structure diagram class diagram object diagram component diagram deployment diagram and package diagram a port defines the point of interaction between the classifier instance and its environment or between the behavior of the classifier and its internal parts composite structure diagram supports the notation for provided and required interfaces if necessary interfaces can be shown or hidden in the diagram a line that represents the relationships within the model is called a connector when modeling the internal structure of a classifier we can use a connector to indicate a link between two or more instances of a part or a port a connector defines the relationships between the objects or instances that are associated with the roles in the same structured classifier and defines the communication between those roles as an example here's a simplified composite structure diagram for a computer system which includes the following components power supply unit hard disk dvd motherboard central processing unit and memory module you can pause the video here to study the diagram profile diagram is one of the uml structural diagrams it is well known for providing a general extension mechanism for customizing uml models for specific domains and platforms profiles are defined using stereotypes tag value definitions and constraints that apply to specific elements of the model such as classes attributes operations and actions a profile is a set of extensions that jointly configure uml for a specific domain for example aerospace medical or financial or specific platform such as j2ee or net profile diagrams have three major types of extension mechanisms stereotypes tags and constraints stereotypes allow us to increase the vocabulary of uml you can add and create new model elements derived from the existing ones but having more specific properties that are suitable for a specific domain stereotypes are used to introduce new building blocks that speak the language of your domain and look primitive this allows you to introduce new graphical symbols for example when modeling a network you may need annotation for router switch hub etc a stereotype allows you to make these things appear as primitive as possible why would you need that for example a box labeled with a stereotype button makes more sense than a picture of green rooster that was added to the schema just because someone ran out of meaningful symbols tags are used to extend the properties of uml so you can add additional information to the specification of a model element this allows you to specify keyword value pairs of a model where keywords are attributes tagged values are graphically displayed as strings enclosed by the curly braces for example imagine a team that is responsible for assembling testing and deploying a system for them it is necessary to monitor the version and test results of the main subsystem and this is where tags come in handy tags can also be useful to add properties to the model such as code generation version control configuration management and authorship constraints are properties used for semantics or conditions that should always be satisfied they allow us to expand the semantics of the uml building blocks by adding new protocols a constraint is displayed as a string enclosed by the square brackets next to the corresponding element for example when developing a real-time system it is necessary to supplement the model with some necessary information such as response time for instance constraints may be placed on attributes derived attributes and associations they can also be attached to one or more model elements shown as a node as an alternative to creating a new matter model you can also expand and modify the uml metamodel according to your requirements in uml this is called a lightweight extension based on stereotypes and profiles a uml profile can be defined in one of the following ways creation of a new meta model extension and modification of the uml metamodel extension of the uml meta-model with language inherent mechanisms uml 2.0 allows you to use arbitrary data structures for extended elements which means that wider and more accurate extensions of the model are now possible the profile mechanism is not a first class extension mechanism because it does not allow changing existing or creating new meta models profile only allows adaptation or customization of an existing meta model in uml 2.0 or above profiles can also be dynamically combined so that multiple profiles can be applied on the same model at the same time a stereotype can extend from one or more meta classes such extension is depicted as an arrow with a continuous align and filled arrowhead that goes in the direction from the stereotype to the metaclass stereotypes can be presented in the form of text or graphics the normal class box can also be replaced by the icon for example people often use these three stereotype class representations to model the mvc software infrastructure to use stereotypes in a specific application you must first integrate a profile containing stereotypes you do this with a dashed arrow its open arrowhead is pointing away from the application package towards the profile this arrow is marked with a keyword apply a profile is applied to another package to make stereotypes in the profile available for this package this diagram shows the network telecommunications and software profiles that apply to the it company suite in this diagram we define the ejb profile as a package the bean itself expands from the component metamodel as an abstract bean an abstract bean can be instantiated as an entity bean or session bean ejb has two types of remote and home interfaces ejb also contains a special kind of an artifact called a jar file for storing a collection of java code use case diagrams are fairly simple they summarize some of the relationships between use cases actors and systems but they don't show the order in which steps to achieve the goals of each use case are taken they usually contain only a few simple figures therefore if you have more than 20 use cases you are probably using the diagram incorrectly there are many different uml diagrams that serve various purposes very often it is possible to describe the details of a system using other uml diagrams and link them together with use cases because use cases represent only the functional requirements of the system other requirements such as business rules quality of service requirements and implementation restrictions must be presented separately again with other uml diagrams use case diagrams are usually constructed at an early stage of development and are often used for the following purposes to specify a system context to capture system requirements to validate system architecture and to drive implementation and generate test cases and usually all this is developed by analysts together with domain experts so what does the use case diagram consists of actor in a broad sense one who interacts with the system and in most cases one who creates a use case actor is usually drawn as a little genderless humanoid with a name on it acta plays a role in the business process quite similar to the concept of a user but the user and this is important can play different roles for instance a professor can be a lecturer at the uni as well as a scientist in some kind of a research lab so in this case the professor plays two roles in two different systems actor triggers use cases in other words actors interaction with the system and how the system reacts to those interactions form the use case acta also has some expectations from interactions with the system if we expect one thing but get something completely different then the system function responsible for the use case may have been either improperly modeled or improperly implemented use case it is a system function or a process that can be either automatic or manual the name is usually constructed from a combination of verb and a noun or phrases that guide to do something each actor must be associated with a use case while some use cases might not be associated with actors use cases determine the expected behavior that is what should happen but they don't describe how to make this happen use cases can be indicated in text or graphic form for example in the form of a use case diagram the main point of modeling the use cases is to help us to design the system from the perspective of the end user by indicating all possible actions of the system that might be externally visible communication link actors can be connected with use cases via associations indicating that the actor and the use case communicate with each other through messages this is graphically shown with a solid line system boundaries for large and complex systems each module may be the boundary of the system but potentially it may be the entire system for instance if we'll have a look at an erp system each one of the modules such as personnel payroll or accounting can form a system boundary for use cases specific to each of these business functions the entire system can span through all of these modules displaying the overall boundary of the system use cases form various kinds of relationships the duty of defining the relationships between two use cases falls on the shoulders of software analysts of the use case diagram reusing an existing use case with other types of relationships reduces the overall effort required to develop a system let's look at the main relationships between use cases use case diagram illustrates a set of use cases for the system an example subjects and relationships between subjects and use cases extends indicates that for example use case invalid password may include under the conditions specified in the extension the behavior specified in the base use case login into account imagine that we have a use case that describes the interaction of an actor with an account for example the possibility of a login the basic use case is extended by two other use cases for example the already mentioned invalid password in which case the system will react in one way and on the contrary correct password in which case the system will most likely react differently extensions are important because they show additional functionality or system behavior this type of relationship is used to include optional behavior of the use case that extends the base use case in our example the student requests a schedule and this requires the extension of the base use case request schedule with the use case search when one use case is shown using the functionality of another use case the relationship between them is indicated by their include stereotype this type of relationship means that an instance of the base use case will include the behavior as specified in the child use case and it is indicated by a dashed arrow with its tip pointing to the child use case include adds additional functionality not specified in the base use case and is used to add general behavior from the included use case to the basis case in order to support the reusage of the common behavior generalization or inheritance this is a parent-child relationship between use cases where the child use case is an extension of its parent use case generalization is depicted by a solid line with a triangular arrow hat pointing at the parent use case in this type of relationship the child use case inherits the behavior and semantic component from the parent use case a child use case may add or override the behavior of its parent in this example the parent use case search has two children search by lecturer and search by date this use case diagram depicts a car sale system and you can probably notice that even such a complicated system can be described with just 10 use cases here you can observe extensions inclusions and associations that connect actors with use cases now a couple of tips to model a use case diagram more efficiently in case you will decide to do so in your project always structure and organize a use case diagram from the perspective of actors use cases should start off simple and at the highest view possible only then we can move towards refinement and high digitalization use case diagrams are based on functionality and therefore should focus on what and not on the how activity diagram is another important uml behavioral diagram used to describe the dynamic aspects of a system activity diagram is essentially an extended version of a flowchart that models the transition from one activity to another and it shows how system activities are coordinated to provide a service that can be at a different level of abstraction first of all let's go over the basic notation of the elements in the diagram and move on to the examples initial node it starts the flow when the activity is called from the outside control flow it shows the sequence of execution of flow action a task to be performed decision node it represents a test condition to ensure that the control flow or object flow only goes down one path merge node it merges the various threads that were created after the decision node fork node splits behavior into a set of parallel or concurrent flows of activities join node it combines several parallel flows usually separated by a fork node object represents an object in a thread that is being acted upon this is an optional element of the diagram but in some cases it is necessary to show the object initiating the execution of activities or being created as a result of some early initiation activity final note it terminates all flows in an activity swimlane a way to group activities performed by the same actor on an activity diagram or simply group them in a single thread the following steps of the activity diagram describe the workflow for creating a document in a text editor open the text editor create a document save the document enter the text if graphics are necessary import them into the document if a table or a spreadsheet is necessary create the required table or spreadsheet and import it into the document save the document print the document exit the text editor seems pretty logical and simple now let's imagine that we were given a task to simulate the order processing workflow using an activity diagram the description of the process is as follows once the order is received the activities split into two parallel flows one fulfills and sends the order and the other process the invoices on the order processing side the delivery method is determined depending on the conditions of the order and transformed into action overnight delivery or regular delivery after sending the invoice for the goods the payment process side is going to receive payment hopefully finally to parallel flows join and finalize the order processing another example is the process for student enrolment in programming courses a student decides that he or she wants to become a super coding guru goes online discovers some online courses and commits to enroll then fills in the registration form on the company's website if the form is filled in correctly then the student is registered if not the student is notified to correct the errors and try again after that the student can check out our free introductory course after completing or skipping it the student can start our full-fledged course straight away finally the student needs to pay for the course success but there is another interesting way to add clarity to the diagram i suspect that the person who has invented the first activity diagram was probably a passionate swimmer because he or she introduced the concept of a swim lane as a part of the diagram swimlane is a way of grouping activities performed by the same actor in a single thread let's have a look at the activity diagram that describes the business process of onboarding a new client first of all we reach out to our potential client and arrange a meeting depending on whether there will be a meeting and whether it will be in our company's office or in the client's office we are preparing either a conference room or just take our laptop with us but regardless of where the meeting is going to take place we know that the client wants to meet with us after the meeting we'll normally send a follow-up letter to the client we just had a meeting with decision point if we have a deal then we prepare the contract and we also add the comment that there is another a separate activity diagram that reflects this process and needs to be followed we send the contract to the client and we get to the point where the process finalizes by the way we come here even if we didn't get the deal and here is a schema of the same process but this time we're using swimlane you can see that now it looks much more accurate because this time the process is divided into areas of responsibility for the salesperson who organizes the appointment as well as writes a follow-up letter to the client and the consultant who prepares the presentation for the client holds a meeting and crafts and sends the contract and a secretary whose task includes preparing the conference room in case the meeting takes place in our company's own office the behavior of an entity is not only a direct result of the input but it also depends on its preceding state uml state machine diagram or sometimes referred to simply as state diagram or state machine or state chart shows the various states of entities state machine diagrams can also show how an entity reacts to various events moving from one state to another and can be used to model the dynamic nature of the system state machine diagram is typically used to describe the state-dependent behavior of an object an object reacts differently to the same event depending on the state it is in although state diagrams are mainly applied to objects they can be applied to any element that changes behavior in relation to other objects such as actors use cases methods subsystems systems etc and they're usually used in conjunction with sequence diagrams state machine diagram describes all events as well as states and transitions for a single object a sequence diagram describes the events for a single interaction across all objects involved let's have a look at the notation used in the state machine diagrams state is a constraint or a situation in the life cycle of an object in which a constraint holds the object performs a certain activity or expects an event an event is a significant occurrence allocated in time and space in the context of states an event is the occurrence of a stimulus that can initiate a state transition guard condition is evaluated after the state transition trigger event occurs you can have several transitions from the same initial state and with the same event trigger if only the guard condition do not overlap a guard condition is evaluated only once for the transition at the time when the event occurs the boolean expression can refer to the state of the object a transition is a relationship between two states indicating that an object from the first state will enter the second state when the specified event occurs and the specified conditions are satisfied an action is an executable atomic computation that changes the state of the model or returns a value a state is a point in the life cycle of a model element that satisfies some condition where some specific action is performed or where some event is expected there are also two states with a specific predefined role first one is the initial state which is indicated by a solid circle a transition from the state will show the first real state and the final state which is shown as a concentric circle in case of an open-loop state machine an object may terminate before the system terminates while a closed-loop state machine diagram does not have a final state if it is the case then the object lives until the entire system terminates events are occurrences that cause objects to transition from one state to another an event can be one of four types signal event corresponds to the arrival of an asynchronous message or signal call event corresponds to the arrival of a procedural call to an operation time event occurs after a specified time has elapsed and change event occurs whenever the specified condition is met transition lines depict movement from one state to another each transition line is marked with an event that triggers the transition considering a system as a collection of states and transitions between states is very useful for describing complex behavior understanding state transitions is an important part of system analysis and design transitions between states occur as follow the item is in its original state event occurs action is performed element enters target state multiple transitions occur either when different events lead to the termination of the state or when there are guard conditions on their transitions transition without an event an action is known as automatic transition action is an executable atomic computation which includes operation calls the creation or destruction of another object or sending of a signal to an object the action is associated with the transitions during which the action is not interruptable for example entry or exit this diagram shows the state of the my bk copy object from the book copy class entry action is any action that is executed whenever an object enters the specified state exit action is any action that is executed whenever an object leaves the state now let's talk about substates a simple state is a state that does not have a substructure a state that has substates or nested states is called a composite state substates can be nested at any level a nested state can have at most one initial state and one final state substates are used to simplify complex state diagrams showing that some states are possible only within a specific context state diagrams are often used for deriving test cases here is a list of possible test ideas idle state receives to hot event idle state receives to called event the calling startup state receives the compressor start event calling ready state receives a fun run event the calling run state receives ok event calling run state receives a failure event failure state receives error reset event heating state receives an okay event heating state receives a failure event nested states are necessary when the activity involves concurrent sub-activities in this diagram an auction was modeled with two concurrent sub states bit processing and payment limit authorization in this example the state machine first entering the auction requires a fork at the start into two separate threads each substate has an exit state to mark the end of the thread if there is no abnormal exit which is cancellation or rejection then the exit from the composite state occurs when both substates exit unless it's specified otherwise when a transition enters a composite state the action of the nested state machine starts over again at the initial state unless the transition is aimed directly at the substate history states allow the state machine to re-enter the last substate that was active prior to leaving the composite state a history state is indicated by a circle with the letter h inside uml sequence diagrams are interaction diagrams that detail how operations are performed they capture the interaction between objects in the context of collaboration and show how elements interact over time and are organized with respect to object horizontally and time vertically the horizontal axis shows elements that participate in the interaction and they can appear in any order typically objects participating in an operation are listed from left to right according to when they participate in the message sequence the vertical axis shows the progressing time but note that time in the sequence diagram is denoted in the context of the execution order that is the sequence itself and not the actual duration there are timing diagrams just for that the vertical space in the interaction diagram has nothing to do with the duration of interaction as an example we will consider the hotel booking service the object that initiates the message sequence is the reservation window note that class and object diagrams are static model views but interaction diagrams are dynamic let's look at the basic notation of the sequence diagram actor a type of role played by the instance that interacts with the subject for example by exchanging signals and data actors represent the roles played by users external equipment or other actors actor does not necessarily represent a specific physical entity but simply a specific role of some entity a person can play the role of several different actors and conversely an actor may be represented by multiple different people lifeline he represents an individual participant in the interaction and displays the passage of time activation the thin rectangle on the lifeline indicates the period during which the element performs an operation top and bottom of the rectangle are aligned with the start and end of a specific function call message used to call procedures execute operations or designate individual nested control flows one end of the arrow always touches the control focus or lifeline of the client object that triggers the message the tip of the arrow points at the lifeline of the object that receives the message and takes action as a result at the same time this object also often receives a control focus becoming active the message can be synchronous depicted with a filled arrow when the client sends a message for example to the server and waits for a response before doing anything else and a synchronous depicted with a regular arrow when the client continues to perform operations without waiting for a response return message return message identifies the specific communication between the lifelines of an interaction and represents the transfer of information to the caller of the corresponding message self message a participant sends a message or command to itself create message in the case of creating a participant we draw an arrow pointing at the participant's rectangle if the participant will perform something immediately after his creation then straight after the participants a rectangle we will need to draw the activation destroy message the destruction of a participant is indicated by a large x with an arrow pointing from the participant that initiates the destruction towards the one that is going to be destroyed if the x is drawn at the end of the participant's lifeline and there is no arrow from another object then this means that the object deletes itself in other words self-destructs note or comment gives the ability to attach various nodes to elements a comment carries no semantic force but may contain useful information focus of control this is essentially any point in interaction where something happens and it is drawn as a tall thin rectangle on the lifeline since the control focus represents a period during which an element is performing some operation the top and bottom of the rectangle are aligned with the initiation and completion time respectively uml 2.0 introduces sequence or interaction fragments a sequence fragment is represented as a box called a combined fragment that includes some of the interactions within the sequence diagram the fragment operator in the top left corner indicates the type of fragment which can be one of the following alt multiple alternative fragments only the one whose condition is true is executed message or group of messages is separated from each other by horizontal dashed line this type is used to simulate conditional statements like if then else and select statements case or switch opt the fragment is executed only if the provided condition is true and it is a call to an additional message or group of messages under some condition it is similar to the old fragment when the shorthand conditional statement if then is used par parallel message processing message or group of messages processed in parallel are separated from each other by horizontal dashed lines loop as obvious as it looks it is used to simulate loops break early termination of message processing on condition used as a part of other fragments usually loop critical exclusively processed message or group of messages used as a part of other fragments usually par implies the suspension of any messages processing in a more general fragment for the duration of message processing inside the critical subfragment neck message or event generated as a result of the inability to process another received message for example if the time for entering the password has expired then instead of returning the password the timeout message will be generated a third it's when a message or group of messages executed after some condition has been pre-checked if the condition is negative then no message is sent in programming this technique is always used to localize errors strict sequential message handling consecutively processed messages are separated from each other by horizontal dashed line and processed strictly in turn from top to bottom sec non-strict sequential message processing messages are separated from each other by horizontal dashed lines and can be processed in any order except for messages received by one object ignore messages that can potentially occur in the fragment and that are listed after the word ignore in curly braces will be ignored ref a reference to a portion of the interaction defined elsewhere perhaps in a different diagram this element is similar to predefined processes in flowcharts or interaction overview diagrams sd used to surround the entire sequence diagram now that we know what's what let's use our knowledge to model a script that consists of some use cases in our case customer requirements are described as use cases that are formalized in the script as a reminder a use case is a set of interactions between external actors and a system to be more precise a specification of a sequence of actions including variants that a system or object can perform interacting with actors of the system a script is a thread that describes a sequence of events that occur during one particular execution of a system that is often represented by sequence diagram for example in this sequence diagram there are two scenarios the main one and the alternative one following the main scenario the buyer enters the author's name in the search box and clicks the search button the system validates the search query if the validation passes the system searches the catalog for the author's books when the search is complete the system displays its results an alternative scenario is rather short if the buyer did not enter the author's name but clicked on the search button then the system displays an error message similar to sequence diagrams communication diagrams are subtypes of interaction diagrams and show how objects interact with each other communication diagrams or as they were called prior to uml 2.0 collaboration diagrams essentially are the extensions of object diagrams that show these objects along with the messages that objects sent to each other the main purpose of communication diagrams is model the messages passing between objects or roles that deliver the functionalities of use cases and operations model mechanisms within the architectural design of the system capture interactions that show the past messages between objects and roles in collaborations model alternative scenarios within use cases or operations that involve the collaboration of various objects and interactions and support for identification of objects hence classes and their attributes in this case message parameters and operations messages that are involved in use cases let's analyze a simple example of a communication diagram where objects for example actors in use cases are drawn as rectangles the objects are object 1 object 2 object n minus 1 and so on until object m messages passed between these objects are represented by a labeled arrows that start with the sending object or actor and with the receiving object examples of messages passed between objects are marked as message 1 message 2 message 3 etc where the numeric prefix of the message name indicates its order in sequence object 1 first sends message 1 to object 2. object 2 in turn sends object n minus 1 message 2 and so on messages that objects sent to themselves are referred to as loops for example message five or here is another example hotel room reservations each message in the diagram has a sequence number the top level message is number one messages sent during the same call have the same decimal prefix but surfaces 1 2 etc depending on when they occur communication and sequence diagrams are similar they are semantically equivalent it means they represent the same information and we can turn a communication diagram into a sequence diagram and vice versa the main difference between them is that in the communication diagram the elements are organized according to space and in the sequence diagram according to time so in which case we would want to use a communication diagram instead of a sequence diagram first of all communication diagrams are very useful for visualizing relationships between objects that collaborate with each other to perform a specific task this is difficult to determine from a sequence diagram in addition communication diagram can also help to determine the accuracy of a static model for example class diagram here is a real world example where we can compare both diagrams in action the process of returning a book to the library imagine a student brings a book to the library and a librarian brings up records to check whether the book was returned on time and whether the borrowing period was exceeded in that case there may be a fine in essence both diagrams contain objects and messages and it becomes obvious that it is much easier to determine the time ordering of messages by looking at the sequence diagram but it's easier to see the relationships between objects by looking at the communication diagram objects involved in communication are of two types supplier and client supplier objects are objects that supply the method that is being called and therefore receive the message client objects call methods on supplier objects and therefore send messages connectors drawn between objects in communication diagram are links that allow to establish relationships between objects and show the ability of objects to send messages to each other if an object sends message to itself then such a link is represented as a loop icon the loop can be seen on both the ui object and the transaction object messages in communication diagrams are shown as arrows pointing from the client object to the supplier object typically messages represent a client invoking an operation on a supplier object message icons have one or several messages associated with them messages are composed of message text prefixed with a sequence number this sequence number indicates the time ordering of the message for example in this diagram we can follow the sequence numbers to determine the order of messages between objects the first message in the communication diagram is always numbered one the second two and so on we can indicate that the message is nested within the parent message by adding a decimal point and additional digit to the parent's ordinal for example the message carl amt can borrow that is calculate for how long the book can be borrowed is the first nested message in the enquire borrower literally request the details of a person who borrows and is given a serial number 1.1 the second nested message in inquire borrower is display invalid msg that is display an error message therefore is given a sequence number 1.2 let's look at the example of transition from a sequence diagram to a communication diagram the client creates a transaction and performs an operation with messages a d and o after that another two transactions put values of p1 p2 p3 and p4 to the database more after that the client receives a message that the transaction was completed and finally the transaction is destroyed and now the same sequence of operations only on the communication diagram the client creates a transaction performs an operation with messages a d and o next to transactions put values of p1 p2 p3 p4 to the database and after that the client receives a message that the transaction was completed finally the transaction is destroyed there are a few things to watch out for control focus also known as execution occurrence or activation shown as a tall thin rectangle denoting the period during which an element performs an operation the top and bottom of the rectangle match the start time and end time respectively in a communication diagram the control focus is explicit and can thus be represented by the message nest numbering finally i would like to show a communication diagram in a format that is also used in some occasions and is called the reliability diagram format we can model objects and instances of actors in communication diagrams along with links and messages describing how they are related and how they interact the deposit element in the diagram describing the recycling machine system describes what happens to the particular objects in terms of how the objects interact send messages to each other and so on you can create a communication diagram for each variant of the use case flow events uml interaction overview diagram illustrates the flow of control of the interactions with the notes that consist of interactions or interaction occurrences in other words it is a high level abstraction that illustrates the flow of activity between diagrams basically overview interaction diagram is like an activity diagram in which the elements were replaced by small sequence diagrams or is like a sequence diagram broken down by the markup of the activity diagram that illustrates the flow of control here are the main nodes used in the diagram initial node decision node fork node join node and activity final node there are several node types such as interaction diagram marked as sd sequence diagram of any kind it may appear in line as an activity invocation reference to the interaction marked as ref also called interaction use with its help large and complex sequence diagrams can be greatly simplified it is also common to reuse some interaction between several other interactions so let's analyze the diagram step by step the diagram shows an example of an onboarding process the employee must first accept or reject the offer note that second option does not contribute to the onboarding process after accepting the offer the employee must register with hr and apply for a company car after both actions were completed the employee must actually begin to work for example on board new customers if the employee doesn't do that after a certain probation period the contract gets terminated here are a few more examples to examine here is how we can depict the interaction with the code lock on the door using the interaction of view diagram interaction use and the code first appears with the argument invalid code then the interaction follows indicate that the code is entered incorrectly which is displayed on the diagram using the built-in fragment from the sequence diagram the following is a decision node with a valid pin code interaction constraint this means that only if the code is entered correctly the grant access interaction follows this is followed by an interaction use let's call it door opening the door is now unlocked end of story but if the code was entered incorrectly nothing will happen however we'll also be redirected to the activity final note and here is a simple hotel room reservation scheme however this time we utilize only the interaction use notes to provide a high level of abstraction register the website select available room type and dates there are no rooms available for these dates we are redirected back to where we can choose other rooms or dates if all goes well then we proceed to checkout if everything is fine there as well the room is booked of course this is a primitive example and we would potentially append the diagram with many more additional interactions but it still gives you a sense of how the interaction overview diagram works timing diagrams are uml interaction diagrams that are used when the main purpose of a diagram is to indicate the intervals between state changes of various objects timing diagrams focus on conditions changing within and among lifelines along the time axis and describe the behavior of both individual classifiers and their interactions focusing attention on time of events causing changes in the modeled conditions of the lifelines transition from one state to another is a change in the level of the lifeline during the period of time when the object is in a given state the timeline runs parallel to that state a change in state is displayed as a vertical change from one level to another the reason for the change as in the case of a state or sequence diagram is the receipt of a message or request of an event that causes a change this so-called stimulus or it could be that the change of the system state occurred by itself triggered by the passage of time this diagram shows alternative notations of the uml timeline diagram in particular the state of the object depicted between two horizontal lines that intersect each other on each change of the state the lifeline is an element that represents an individual participant in the interaction usually it is horizontally aligned to be read from left to right multiple lifelines may be stacked within the same frame to model the interaction between them the state timeline is a set of valid states of elements and time states are stacked on the left margin of the lifeline from top to bottom it is possible to stack several lifelines of different objects in the same timing diagram placing one lifeline above the other messages sent from one object to another can be displayed using simple arrows the stats and the end points of each arrow indicate when each message was sent and when it was received the state lifeline indicates the change of state of an element over time the x-axis displays elapsed time in any selected units while the y-axis is marked with a list of states the value lifeline illustrates the change of elements of value over time the x-axis displays elapsed time in any selected units similar to the state lifeline the value is written between a pair of horizontal lines that intersect each time the value changes we can use the length of the timeline to show how long the object remains in a certain state reading it from left to right in this diagram the login event is received after three units of time from the start of the sequence to show relative times we can mark a specific instance in time using a variable name this diagram marks the time when sendmail event was received using the letter t we can use a relative timestamps in constraints to indicate that a message must be received within a certain amount of time state and value lifelines can be stacked together in any combination messages can be transmitted from one lifeline to another each state or value transition can have a certain time limited event which indicates when it should happen and a duration constraint that indicates how long the object will be in that state or will be affected by the certain values here is an example where we simulate a car park system using this sequence diagram it shows the consistency of the model between two interaction diagrams the timing diagram must always match the sequence diagram and state diagram in order to achieve this we can attach states to the lifeline of each object in the sequence diagram in this case we can derive the corresponding timing diagram much easier by checking the messages sent between objects against the states attached to the lifeline so here is the same car park system presented in the form of a timing diagram

Channel: freeCodeCamp.org

Views: 190,580

Rating: 4.9562945 out of 5

Keywords:

Id: WnMQ8HlmeXc

Length: 101min 31sec (6091 seconds)

Published: Wed Apr 21 2021