Analyze and Improve User Requirements Using Wireframes, UML, and ERD | Ahmed Fawzy | Skillshare

Playback Speed


  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

Analyze and Improve User Requirements Using Wireframes, UML, and ERD

teacher avatar Ahmed Fawzy, IT Transformation Advisor

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

24 Lessons (4h 8m)
    • 1. Introduction

      2:42
    • 2. Project Delivery & DevOps Overview

      11:51
    • 3. Requirements Collection Overview

      23:07
    • 4. Prototype's

      22:38
    • 5. Prototype's Best Practices

      7:20
    • 6. Prototype's Testing and Feedback

      7:44
    • 7. UML Introduction

      7:52
    • 8. UML Overview

      9:59
    • 9. Software operations Stakeholders

      3:43
    • 10. Class Diagram

      17:21
    • 11. Use Case Diagram

      12:03
    • 12. Sequence Diagram

      9:03
    • 13. Communication Diagram

      6:15
    • 14. State and Activity Diagram

      13:47
    • 15. Deployment Diagram

      7:53
    • 16. Component Diagram

      9:54
    • 17. Package Diagram

      5:36
    • 18. Object Diagram

      4:56
    • 19. Timing Diagram

      9:37
    • 20. Interaction overview Diagram

      4:41
    • 21. Composite Structure Diagram

      5:13
    • 22. Profile Diagram

      6:16
    • 23. Entity-Relationship Diagram

      21:11
    • 24. Deployment Consideration

      17:01
  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.

142

Students

--

Projects

About This Class

Learn How to Analyze and Improve User Requirements

Have you ever gotten feedback from a client where they said, "This is not what we wanted"?  Do you have a way too many change requests in your software project? Do you face challenges when performing UAT?

In this class, you get the answer to the question, “How do I align business analysis ideas to ensure more precise customer requirements?”

Whether you are trying to communicate ideas to your stakeholders or defining the details requirements and specifications, this Class explains how to develop a value-added software application that meets both requirements and specifications.

The Instructor walks through a rich analysis and the design process, explaining the need for prototypes like wireframes, ERD, and UML, and how to use them.

This Class describes a step-by-step approach for producing several diagrams as prototypes. It will allow you to get the desired feedback quickly and accurately before handing it over to the designers and the developers.

The Class is for business analysts. It does not require any programming knowledge, nor does it require prior experience in UML, design, or databases. In this Class, business analysts expand their toolkit to get more precise and exact requirements by mapping the requirements to design, application models, and databases.

In this Class, you will:

*Get an overview of project management, DevOps, and requirement gathering

*Learn how to think about application layers, interface, logic, and data storage

*Capture and precisely represent application requirements

*Learn how to capture the system's requirements to ensure that your prototypes meet your stakeholders’ needs

*Learn how to deploy the system to the real world

*How to draw models as a requirement gathering tactic

*Learn how to agree on the designs and the models before starting the project

*Learn how to build wireframes to produce effective user interface design and architecture

*Understand what UML models mean and how to use them as a tool for requirement gathering

*Represent requirements better with your business customers

*Improve your skills in presenting your system in different ways

*The ins and outs of application models. This book cuts to the fundamental design logic and simplifies the language to basic concepts.

Learn how to model your system and parts relationships

Learn the core concepts of cloud computing (IaaS, SaaS, PaaS)

Get an overview of microservices and containers

 

If you are serious about modeling your ideas clearly and quickly to get the exact requirements and feedback, then this Class is for you.

Full Description

Class 1, Project Delivery—In This Class:

*Overview of Project Delivery

*Overview of DevOps

Class 2 Value and Requirements—In this Class:

*Understand the business process

*Requirements gathering

*Initial Diagrams

Class 3 Prototypes—In this Class:

*Prototyping Overview

*Prototyping Application Interface

*Mock Design

*Wireframe

 Class 5, 6, 7, 8, 9, In these Classes, you will learn:

Class, Use Case, Sequence, Communication, State, Activity, Deployment, Component, Package, Object, Timing, Interaction Overview, Composite Structure, Profile Diagrams

Class 10, Entity Relationship Diagram—In this Class:

*Database Overview, Design, and Optimization

*Entity Relationship Diagram (ERD)

Class 11 Deployment Consideration—In this Class:

*Cloud Computing

*Application Architecture

*Containers

*Network Communications

Meet Your Teacher

Teacher Profile Image

Ahmed Fawzy

IT Transformation Advisor

Teacher

Ahmed Fawzy, is an Advisor, Author, and Online Trainer. He has 18 years of experience in the fields of IT transformation. Utilizing a unique approach to achieve a better alignment to the business through solutions and processes. Also, how to transform IT organizations successfully from "Traditional to Digital."

Ahmed holds ITIL Expert certification and ITIL4 MP. He is also a certified Project Management Professional (PMP), TOGAF 9 Certified, and has a Master in Business Administration (MBA).  He has implemented improvement programs for a wide variety of organizations. His approach is unique because it doesn't require new additional software or hardware,  "It's simple few adjustments that yield a high return." Ahmed's goal is to help leaders transform their IT internal o... See full profile

Class Ratings

Expectations Met?
  • Exceeded!
    0%
  • Yes
    0%
  • Somewhat
    0%
  • Not really
    0%
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.

Transcripts

1. Introduction: In any application, simple or complex, you need three main things. You need to interface the logic and delete the data storage. In this course, you will learn how to analyze and improve user requirements. How to turn user requirements into more exact specifications. Whether you're trying to communicate ideas to your stakeholders or defining said ETL, the requirements and the specification. This course explain how to develop a value added software application that meet both requirements and specifications. We will walk through a reach analysis and design process explaining the need for prototypes like wireframes, ERD and UML, and how to use them this course to describe a step-by-step approach for reducing civil diagrams as prototypes. It will allow you to get the desired the feedback quickly and accurately before handing it over to the designers and developers. This course is for business analysts. It does not require any programming knowledge, nor does it require any experience and your mail design or databases in this course, business analysts expands their toolkit to get more precise and exact the requirements, mappings requirements to design application models and databases. In this course, you will get an overview of project management, DevOps, and requirements gathering. Learn how to think about application layers, interface, logic and data storage. Capture and precisely represent application requirements. Learn how to capture the system requirements to ensure that your prototypes meet your stakeholders needs. Learn how to deploy the system to the real world. How to draw models as requirement gathering tactics. Learn how to agree on the designs and the models before starting the project. Learn how to build wireframes to produce effective user interface design and architecture. Understand what your model mean and how to use them as a tool for requirement gathering. Improve your skills in presenting your system in a different ways. Learn how to model your system and parts relationships. Learn the core concepts of cloud computing IS SAS and pass. Get an overview of microservices and containers. If you are serious about modelling your ideas clearly and quickly to get the exact requirements and feedback, then this course is for you. 2. Project Delivery & DevOps Overview: Before we start, we need to brush up on few concepts to ensure you understand the upcoming topics very clearly. The first topic I want you to remember is the project deliver methodology. Change to the organization operations. That you would have a positive impact by removing risks or constraints on the organization's operation. In any projects, three, constraints exist. You have scope, schedule, and goals. Changing, one will change the other two as well. The role of the business analyst is to ensure that the changes made to one constraint will impact the other two in a controlled manner. The idea of project delivery is how to get from one state to another and how to manage the project to move from the S is the current two to b, which is the two methods are available, waterfall and a giant. First, let's remember waterfall project. It's a project with a single direction flow. The project that only moves to the next step. Once finished, the current step. This is the traditional way of delivering the project. And it's around for ages. You start with a plan, going through that design, implement and verify. And lastly, Hugo, to maintain, you have to do it in this order. And you're going to get like a waterfall from top to down, from planning until maintain. You cannot go the other way around. In software projects. This cold, so many issues because simply between the time you are getting the requirement to the actually delivering, implementing, verifying, maintaining the software could take years, which led to a lot of software project failures. This led to an adjoint project. It's iterative project, which mean the planning and clothing only once you do the initial planning in the beginning of the project and you do the closing at the end of the project. But the remaining will go in circles. I'm still finishing the project. The loops the project goes into the produce value. The shorter the better. The typical sprint duration is two weeks with a maximum of four weeks, are just these values to fit the project needs. You have also what's called a backlog. A backlog is a list of requirements, is a list of what the team will deliver. It's the view of all the items that are in the queue. So what are the adjoin ALL phases. The first adjoined faith is called Envisioning faith. What the project is trying to build, chartering, chartering the project and building the team. Next you have clicking elite phase. The first phase of the sprint, what features or requirements to satisfy the business need you will include answer Sprint, the feature based delivery plan, estimated risks, maintain the feature board showing the progress and the issue logs of sprint and the overall project. Next you have the xy phase, the second phase of the spread. This is the actual plant work. Review developed features, build issue Log Management. And once finished, that team prioritized feature built and the tasks estimates adapt phase, the third and final phase of the sprint. In this phase, you fix things. You do the final review with our listened, learned, and the project will loop until finishing all the sprints. And finally, you collect feedback. The final phase of the project is a closed phase. Here, deliverables are completed and you make the lesson learned for the whole entire project. This lead us to something in-between. You now have the waterfall and you now have the child. But their need for something more robust foster delivery required us to develop something new. Here comes what is called as DevOps. It is not a methodology, but it's actually a way of developing our software systems while maintaining it at the same time. So let's identify what DevOps is. Part of the DevOps idea comes from Lean. Devops is a practice of Operations and Development engineers participating together in the entire service lifecycle. This improves the deployment and the change Tikal, which leads to higher performance, faster recovery, and fewer failures. You probably noticed that therefore ops is not part of the project delivery. But it changes the way you think about a change. In other wards. A project to your environment at change in DevOps is something minimal. And it keeps building up until we reach the desired goal. Devops is not new position between developers and engineers. Devops is a way of thinking and an approach to building and delivering supporting systems. If an organization is using DevOps tools, it doesn't make it a DevOps organization. They are only using the tools. That's it. Because I see this a lot. If an organization use Docker's Jenkins or factory, it does not make them a DevOps practice. Though DevOps is still very young compared to other practices in IT, like IT S M as one example. The following is the major principle and methodology's that most everyone in the DevOps community agrees on. So first, let's start with DevOps principles. When the word principle is used in most of the frameworks, it means a way of thinking. The principles are the foundation that are applied throughout the implementation that derive all decision in this transformation project. The first one and the most popular in DevOps principles. Cms, Culture, Automation, Measurement and chairing. The culture consists of the change in culture and breaking the barrier between teams so that everyone in the organization can help anyone else. That automation. This is where the tools come in and this is most of the visible part of the DevOps show up measurement. Devops is all about measurement and improvement. So you measure to seek out improvement opportunities and repeat, you go in cycles until you reach the best value to your customers. Sharing this, sharing the knowledge and experience with everyone in the team and the community. The next principle we have if the three ways, system thinking and vilified feedback loops and continuous learning and experimentation doesn't Thinking is focused on the overall results. Don't focus on a specific part of the process. Think of it as an overall amplify feedback loops is considering output when starting the process to discover any potential issue directly and continuous learning and experimentation, you need to have them entelechy of continuous learnings that you are doing things to learn more. And you should be doing a lot of experiments to develop a better ways actually delivering results. Next you have DevOps methodologies. That methodology is a way of applying DevOps to the organization. The following are the most common five methodologies. The first one is called people over process, over tools. This means defining will do the job first, then defining the process around them. And then the tools they will use. You should be applying organizational change and team-building activities in a specific methodology. This is where team-building and organizational change and culture change activities comes into play. Next, methodology you have Lean management work in small batches, amplify feedback loops, do a lot of visualization. This is a process optimization, tried to apply it to every process and practice in your organization. You also have visualizations like reports and dashboards to monitor the process and the practice continuously change. You control this remote operation success and controlling changes. And the last two, which are the most common, are continuous delivery and infrastructure as code. Let's start with continuous delivery because it's the most common and the first thing that comes to mind when someone has spoken about DevOps, This happens by creating a small chunks, run the entire system with every modification in a distinctive environment, and once accepted, ship it out to production, always uses the minimum change possible. Continuous delivery doesn't mean continuous disruption. Users need to know what is changing, when and why. Every bill needs to be tested throughly to make sure it will not fail. 4b reform below expectations, the entire objective is reduced both the cycle time and the time. So what are the cycle time and lead time? Cycle time is the period from the development until deployment. It should be as short as possible. Some say, and DevOps, it should be shorter than the time it takes to make a t or a coffee. Next you have the time. This refers to the time from the request to the deployment. So Lead Time is a little bit of a bigger scope than the cycle time. So if you think about it, lead time is the initial timing from the getting the request until you reach the deployment. And it using the time it takes to implement that change will allow you to before more experimentations and find user system much better. Those enable the methodology is continuous delivery. Sometimes it's called also c, d slash t i because inside the continuous delivery methodology, there are three main levels of delivery control. You have the first-level called continuous delivery, the practice of deploying every application built to production like environment and reforming automatic acceptance testing. The next control you have is continuous integration that the practice of automatically building an entire application. So you have the application automatically build, but it's not actually deployed on anything. And finally, you have continuous deployment. The practice of deploying every application built, production after passing it's automated tests, the challenge is to find the weight or to meet deployment and distinct and find a trustworthy automated tests. That says one of the reasons why continuous delivery is more accepted Zen continuous deployment. Continuous delivery has some manual tests at the end. Before deploying it into production, Think of it as a safeguard that you have to do it manually to confirm its functionality. Unlike continuous deployment, which has everything, automate it, that's all Forza refresher about DevOps and project management theorems and extra video. Thank you for your time. 3. Requirements Collection Overview: Let's do a simple exercise. Close your eyes and think of a car. Next. Ask a few people to do the same exercise. Most probably you will not get the same answer from all the people who will talk to you. This is why getting a group of people to agree on one thing, look, function. Reformers is not so easy because everyone is building their expectations. B has done their background and history. In order to level the playing field, you need to understand the few concepts that will make everyone reached the same understanding across all stakeholders and all people. You need to unify the vision. You have to give them diagrams, you need to give them explanation, because these things vary a lot between different countries, different people, and different backgrounds. To create this same understanding across all people, you need to create a process. You need to understand what is required of your application. The software trying to build is probably a process, even a small process inside the larger one. A process is a transformation action toward one or more goals. It's measurable, has a specific results and has a specific trigger started. Measurable, something that can be measured. If you cannot measure it, it's not a process, has a specific results. It needs to generate some specific outputs. If the output will change every single time you run it, then it's not a process and need to start based on something. All three need to be in a system, in a software. If one of them, you cannot determine, then you're where might not delivers the required function or become part of the process chain as expected from the business. So now we move to Business Process Modelling. Any business is a set of processes. It's a complete system connected to deliver value to an end. The customers, regardless, hoses in the customer will be, it could be an internal user, it could be an external user. It could be a customers that actually buying our product or service under a standing like new system position in the value chain between the operations of the business and the customer that this system is serving is essential to provide the value required. Often, more than we like to admit. Some systems are unnecessary and could be removed from the value chain completely without any impact. So always considers a value as the target. No value from your system equal no system, because simply you will not be able to convince the business that this is a delivered function. And you will keep getting a change request after a change request, after a change request until they reach I want a specific value. So it's better to get the value tackling very early on in the requirements gathering and the initial statement of work in the beginning of the portion. So. Commenting these processes is critical for any organization to stay in the market competitively. Business Process Modelling is a visual way. The organization keeps track of its processes. Moreover, make sure it's matching its goals and objectives. The main benefit is to understand the how the organization run and how to perform activities that will identify any VG or missing process in the organization. The first step is to identify the steps included N3 process. This is why we use a diagramming tools to represent the process in a visual way to ensure that everyone understands the same, to avoid the issue and project delivery and development down the road. The next thing we need to recall is the requirement gathering. What is the tactics? To collect the requirement from the end-users, ends a stakeholder first, conflicting requirements. The first step you need to understand the project scope from the project manager and the project sponsor. A piece of advice here. During the conversation with stakeholders. Watch out for areas out of scope for this project. Sometimes a stake holder will not be able to make a decision. In this case, offered alternatives and they can select one. So how do you actually do the requirement gathering? You have many tools in your toolkit to get the requirements out of the stakeholders. The first one is entry few. Next you have the brainstorming sessions or focus groups. The third is observing a job or a process. You have to get permission and give notice to the employee that he's being watched or or observed. You can do also surveying. You can deliver surveys and Governor requirements. From this, you can do requirement gathering workshops, co-creating a big picture with your stakeholders. During the workshop, make sure there is a shared understanding of the vision of distribution, why build it goals and objectives and the high level scope. The worst situation you will be faced with in the middle of the project that someone discovered a missing requirement from the project. Sometimes it can be added simply, and other times it will require a measure reward. It require a project modification as well. Correct business requirement analysis will save much reward. And there are steps to follow to identify the requirements as accurately as possible. It is a process of discovery, analyze, summarize, and documentary requirements before moving to next steps, The first requirement gathering you need to make is to identify stakeholders who will be touched by your systems. They have something to gain or lose from the project, impacted by the work, or can influence the project. It is essential to know what the requirements and interests are. In some cases, the entire users or stakeholders. But since it's impossible to list all the users, we use a sample to represent the entire user group. The first step to know that a stakeholder is sit down and brainstorm with the sponsor and the project manager who might be involved. It can be people or other organizations as well. Mentioned them all by person. Department, organization name. Don't do a generic names. Don't go for generic terms. Be very specific. I always make sure that the clear majority of the stakeholders know the exact output from the project. To avoid any potential negative impact. Don't be afraid as well of going around explaining the project, collect feedback, and getting some idea who the stakeholders might be. The entire project team should create a list, not just the single person opinion. The next step after creating the stakeholder list is to identify as a business requirement and says Step collected from all the mentioned the stakeholders, the requirements needed. Each one of the stakeholder configured the project only from the point of view. They might identify requirements for the project to scope. Expectation management is critical in this stage. Requirement elicitation is asking the question the right question. The requirement analysis is understanding the answer and discovering new question, leading to how the pieces connect and fit together. There are two main techniques. First one is interviews took to each one of the stakeholders are guided. Interview is preferable. Create a simple few question in advance to guide the entry fewer properly. Next, you have focussed. This will provide input while it shows the integration points between department. In rare cases, a previous attempt on this improvement might exist. Reviewing the previous documentation or discussion with the involved people might be helpful as well. Now we have a list of features and list of requirements. Your next step is to start categorizing the features. You start categorizing them by their importance. This is the first step after the core information is collected. The last question should be, why do they need to such feature? If this is a must or should or nice to have feature, I must feature is a core feature that the business on it. I should feature is a core feature that will speed the cycle of the software. Like simple reporting functionality are nice to have feature is a feature youth for user comfort and ease of access. Your next step is to categorize types. Once the order requirements is collected from all stakeholders, begin categorizing them into the following groups. Functional. This is what the solution should do. For example, the solution should respond to orders in less than five seconds. Nonfunctional the situation and the Environmental Solutions operates in, for example, the up time for the solution, like 99.99% of the time, you have also technical requirements. These requirements are related to how the system is built. Like the OS type, a set of configuration should be transition requirements. These requirements are temporary in nature. For example, if an old system that has served a specific function and the migration of its old data into a new system. Remember, each one of these types need to be categorized, beer importance. So inside the functional requirement, you should have, must-have feature, should have feature and nice to have feature. Your next step is requirement refinement and verification ensures a collected requirement to reflect the current business. Strategy's always ask stakeholders to categorize requirements into muster group, should group and nice to have group in kids, the stakeholder did not know how to prioritize the requirements. Use most analysis prioritization, tick every requirement you have available and assume you will not deliver this requirement. The impact of not doing this requirement will determine if the must-have, should have, could have, or want to have conducted a workshop to verify all gathered requirements and their groups, try to address the requirements that have been dropped and why you drop it. Now you have the basic requirements from the stakeholders before you draw. There are some exercises before you start getting into the actual software drawing. If you don't understand this part correctly, you are missing lots of requirements and taking a big risk. Even if you are on a child or you do continuous delivery, you need to understand the why before a single line of code has written the three tools to validate your understanding or mind maps. This is to ensure you understand everything in a well-connected manner. And you will challenge the stereotype thinking or the implicit requirements that you might have through chart and swim lane. It's all about value. And without understanding how things move from one actor to the next, you will not discover the function the new system is trying to fulfill. The reason behind drawing a flowchart first is to confirm that general understanding of the process. And finally you have fishbone diagram. This simple diagram will allow you to drill deeper to discover the issue this system is trying solve. Let's first start with mind-map. Mind mapping is a thinking and brainstorming tool. You should by now have lots of requirements. Some of which are user interfaces, some performance-based, and some are application function, and many others. You need to draw mindmaps to ensure your understanding things correctly and there is no legit gaps in the requirements. You start by drawing your understanding of requirements in a mindmap. You start by the main topic. In our example, this is, will be the software. It's an oval shape in most of the mindmaps of Twitter. But you can write the word Only if you wish. There is no restriction or limitation. Now, at branches, these are the thoughts you get around this application. It could be anything, anything you think about. When you think about the application, you dump it here after you finalize this step. Now big one of the branches you created in the previous step. And write your thoughts about it. Implicit and explicit. Don't assume anything crosses your mind. Just write it down. In whatever format. You don't have to arrange it. You don't have to do anything, whatever thought you think of, just write it down. Now once you will hit the step, don't try to stop the flow. Just start to follow the logical process. Whatever you think is okay, and making sense, please edit, keep adding until you can no longer include items. It's worth noting that this is not a standard. This is a free form. You can change your branches, move branches around and adjusted as you see fit. Because the more you think about it, the more connections you will discover. And this is the entire purpose of this exercise. Also. Please note, this is an individual exercise. In other words, you're the only one who will see this. And usually you don't ask stakeholders and other team members about this as well. Now, go back to the stakeholder requirements and compare what you wrote to what they requested. Most probably, you will have two cases, things you thought about, but that doesn't exist logical to you, but no one talked about it for some reason. Item z requested, but you did not include. You start with the second one, edit to the diagram and stored the brainstorming around it once more. If you can come up with additional topics or requirements. Now, for the requirements that didn't map to customer requirements, you need to go back to the stakeholders and challenged them why these requirements are not included? The idea is that the more you do this exercise, the more you will reduce the chance of something was forgotten. This exercise is simple enough and can be done in one hour or less. Unlike other prototypes techniques, Once you will build your mind-map, next, you move to flow charts. Before we begin. What are the flowcharts and how does it work? What does a flowchart? The flowchart is a representation or a start and end of a process that contains some logic inside. It gives the picture of the steps necessary for a specific action from a specific actor or entity. So in other words, it's one actor in the system. So what are the flowchart symbols? You have mini symbols in the flowchart. Most of them are pretty standard by now you have the start in simple. Basically, if this is the start and end of any flowchart, you have the decision symbol. This is a yes-no question. You have the process or action symbol. This is the processing done on input from another shape. Like for example, if you have a yes-no question, in this case, this is a processing or the action you will take based on this yes or no question, you have the R0, which is connecting between all fields and all shapes together. And you have a document or a people. This is a physical document. You have the database or a file on a computer. You have an output data. You have a manual action. Manual action, for example, like picking up the phone and calling someone or writing down something. You have a subprocess. If you have a complicated flow chart that you need three direct to some other subprocesses that you can mention a little bit down the road. And you have on-page, off-page connectors. If you have a big flow chart, you need to spend it between multiple pages. So how to build a flowchart? Flowcharts is well known by many names. Sometimes it's called linear flow chart, swimlane flow chart, cross-functional flowcharts. But at the end of the day, they are all relatively the same. Only few differences between them. But there is a symbol principle I would like to reform before I can use my drawing tools to draw the final flowchart, first, get a flip chart and cut down pages, stick them on the ball. And each one of them will be a process. Beach, get a sticky note and write some of the activities and arrows. The shapes we talked about blade with people. Ask them to move them to the correct place or in the correct order. If you use the tool instead, people will try to find the shortest path or the minimum effort. Try to keep it as simple as possible. Always tried to simplify, keep simplifying as much as possible, keeps a details consistent throughout the entire map, no loops. This mean if the problem is not fixed, it don't go boy, entering the arrow to start and follow the entire flow chart. This is considered unnecessary work. The action should be trying several solution. Alternatively, shifting the issue two different process to avoid loops at the decision was account how many times that we receive with this ticket ID, for example, or this problem or a number. I tried to make the flow in one direction, top-down, left, right. Don't go by pointing the arrows in all directions. It would be very confusing to ever trying to read it. Add any shape, but add the bigram key to identify which shape represents what. Once a valid process that all team agrees on have been reached, process the actual flow charter drawing using the drawing tools. So what are the difference between the swimlane chart and the flow chart? Typically, as women lean chart is a high level with lots of subprocesses. Each process has its own thrill chart. As a rule, if an entire process is performed by a single actor, entity, user top-down traditional flowchart, if has many actors uses when Lean, if it's complicated with so many steps, used swim lane to demonstrate the interaction between actors, entities. And for each actor, use the flowchart. Since our example is simple process and for each actor use a flowchart, some drawing application has more attractive shapes than others that will make it much easier to treat and interpret this example, only basic shapes are used. In our example, we will draw the process of user requests have winter and going through the approval process until the printer installation from the user contacting the IT support, the IT support. Then we shifted from the ln of the user to the IT support. Riser requested for approval. Now you have to do new brand through approve approval from the manager. And then you have two choices, either approved or rejected from the manager. If it's approved, IT support will acquire the approval. If it's rejected, we will inform the user and it will go to end. Now back to the branch of approved. Once we will acquire the approval, we will send a printer requests to the purchasing department purchase process going through the purchasing process, which is hidden in our swim lane because it's an outside process that we don't think about for the time being. And going through the Supplier process of supplying the printer. The warehouse process, which is also a subprocess. Once a warehouse receives the printer, it will inform the IT support that required printer is received. Once the IT support received certification from the warehouse, they will go and collect the printer and update the warranty information in the database delivers a printer to the end-user and the end user to grant access to his or her machine, to IT support in order to install the printer. Once the IT support received permission, they can go ahead and install and configure the printers, desktop printer and get the user sign off. Once the sign-off is written, we will file the sign-off into our primary database and storage. This is a very simple process. But just to give you an overview how a flowchart and swim lane is function. There is one thing, additional two flowchart and swim lanes. There used to be this process and drawing style called Business Process Model and Notation. This drawing type is understood by the computer and can run a simulation to determine the bottlenecks on it. Low, this is phasing out. I readily see it nowadays. Most of it are becoming Bartle, unaware of the business process software package. And it has not independent thing. Usually this kind of software comes with some sort of a system engineer to operate the system itself, to test the business process and tell you, okay, if you run this business process, you will have the specific bottleneck, the Business Process Model and Notation is quite simple and almost the same as the flowchart. You can create, one using the displayed URL. This is not necessary if you are interested, you can try it out by briefer logical model on it and adjusted as a go. The last one is the fishbone diagram. Throughout the interviews with users, you will get additional small issues and system limitations that will surface things. The complaint about this might be a symptom of broader issue for this, use, a fishbone diagram. It is fast, straightforward quality tool, M problem analysis tool. The fishbone diagram is drawn in three simple steps. Draw a line that I drew, another line branching out from the primary line. This will be, the primary issue is a main issue are trying to solve. Now, draw contributing or secondary issues branching from the primary issue. After finishing all the issue, there will be a better view of where the main problem is and it will look like a fishbone. It can lead to many other improvement projects a little bit down the road. This is all for this video. See you on the next one. 4. Prototype's: You notice Gooding itself doesn't take that much time. If you're coding right away without any documentation, you could finalize your application much faster. But if you try to come back after a few months to make change or to make a minor adjustment. Or worse. If you have a big team of developers on instead of just one, you will need some common language for all to understand the how things will function and fit together. This is why you are developing all of these models. As mentioned, it is time intensive, but it is a necessary evil. In any application, you have three main layers. From the end layer, which called View layer, some call it Presentation layer. It has so many names. It is the graphical interface. You see it in front of the end user. You have a middleware. This is the mean applications. This is a business rules layer and the access layer and data retrieval. Sometimes it's separated into different components. And sometimes they are all back to N21 middleware application. And at the end you have your data storage, that database. Each layer is addressed through different diagrams and object. However, most diagrams can be used in any layer. Usually some diagrams are reserved for a specific layer. These diagrams that can explain in much clearer way that specific layer exploring all of these diagrams to understand which ones can be employed, in which layer is important to deliver the correct message. As a business analyst, b2 of your role to define all three layers of the requirement, how it will look like, what are the business rules and restrictions? And finally, the database. You rule is to define the requirements and the overview of the all three layers that are required by business application. Surprisingly, looking at all the three layers will give you insights and neat you did not address before. For example, and some regulations. You can use the username and password in one database as specialized dissolution designer. Then take this to the next level and design what's inside the object itself. This mean you will be interacting with three leading solution developers. You have your UI UX designer, you have the developer, and you have the database admin or the tab is architect. Each one of them will be expecting a specific input from you to start designing the details of the solution. If you drop one part of the solution, it might impact the other areas as well. So it's recommended that you lay down the foundations to secure the solution requirements. To lay down this foundation, you start with prototyping. Prototyping is an approximation of the product or service. It is created to explore some aspect of the final product and to ensure that the final product matches the requirements and end-user's specification. So why prototyping is simply to reduce a specific type of uncertainty. And to reduce uncertainty, you need to use many methods. The easiest way is to identify what you don't want. First, let me rephrase. You build things, you know, will fail in some way and distance and collected feedback on the actual requirements. This way, the customer will point out things they like and dislike from this specific model you create it. So the main benefits of the broad pipes are learning. This is a BOC model explaining the usability and the feasibility of a product. Communication. Using the prototype to communicate design ideas effectively. Integration brutal typing subsystems and integrate those to test a complete system to help develop milestones, which is an achievement in the development process. So how do we do prototyping fast? This is what's called rapid prototyping. Rapid prototyping is key to good solution design. Something easy and can be made very fast. Help a great deal when building a product uses symbol medium like papers or even 3D printed objects. In case of a physical product, for example, you'll prototypes doesn't need to cover everything, but it needs to cover a specific aspect of the product, the aspect that have some level of uncertainty related to it. Ideally, it should replicate the whole product. But usually the time allowed and their feedback required a much faster cycle. Then waiting for a full prototype, you need to generate ideas as fast as possible, shake the visibility of the idea first and ensures this is what the end-user wants. And basically, we give the user feedback too late in the process. Using rapid prototyping, you build the prototypes and show it to the end-user. And since this is a prototype, the end-user expected to look unpolished. So they give you honest feedback. The prototypes are divided into multiple groups based on the information collected. Three types of prototyping exists. You have sketching and paper prototype. You have digital prototype, and you have native prototype. But let's start with sketching and paper prototyping. You draw up the interfaces and they will look like to the end-user. Your sketch should be evolving from a rough drawing to a realistic. The paper prototype is the application structure or the user flow. Sketching will allow you to draw ideas in your head with minimum effort as possible. This is the basic application structure. Drawings are what you will be creating this face. You are required to create a basic interface design, a basic application design, and finally, a basic database design. And x_k is the step. You create a high fidelity design. You might be tempted to draw the design on your computer, but tried to hold back and instead try to flesh out as much as possible of the idea on paper. And having the idea on paper will speed up the design work on the computer. Paper prototyping also has another effect. It gets a corrective feedback from users. In the Finnish prototypes, people will hold back because they think you did a great deal of effort on it because you worked on it and no one will like to devalue your work near completion. However, on paper, people will see little effort done. And we'll give you the almost opinion. This will assist you in getting more requirements that were not even discussed before. Things like business rules. For example, cash withdrawing limits and ATM. Next we have our digital prototyping. It is building an idea by using an interactive experience for the user. Using digital interface, we use digital looking designs to ensure that the same idea is the same between the customer and the engineers working on it. This will give the prototype the same look and feel without actually building the actual software or the final product. To do that, you have two steps in this process. Step number one is to build the actual photos using any imaging application. Step two, use a tool to animate these photos. Example for a tool is a tool called principle, or you can have Adobe XD. Next you have native prototyping. Native prototyping is done using grep application real data. This includes writing codes in whatever language you will use in the actual application. People try to avoid these prototypes because it's very high cost. We use it only if the customer is building something with lots of unknowns, like unknown integration point or a new product that did not exist before. Liquid in this prototyping used to demonstrate the functionality. In other words, you'll be taking shortcuts and the shortest path possible to produce something that will function close to the expectation using the common use cases. Afterwards, you start filling in the special use cases and apply the court best-practices. Native prototypes have some types as well that will very invested. And the final prototype, you have four main types. You have exploratory, you build the minimum could needed to make the product function. To make it similarly, the look and feel of the actual product. So it's the look and feel. But with some code behind it, usually has some cost associated with it. It is recommended to do it to avoid costly rework down the road. Next we have throw away. It is the first version of the product that helped you learn about the real requirement, the modify it and reuse the code. But you start from scratch. In this case, this is called throwaway. Next we have incremental, This building the core feature, the feature or the MVP. And then you add more and more feature that will enhance the functionality of the product. Next we have evolutionary. In this, you divide the feature by complexity and reuse the feature as you go along. In other words, you start with fully functional system. But not all options are available. You will have the foundation for all features, but all will be able to coming soon. Then you will. Developing the components one by one incrementally. So you store the interface with the All option, with everything but everything. Whenever you try to click on it, it will give you this feature is coming soon between both. You can even simplify further by mixing the product. For example, you could do a must-have in the simplest form, this is the MVP and then start advancing the feature. Then add the should have in the simplest way, then start growing. And lastly, adds, nice to have in the simplest form and grow. You can call this a hybrid model, some sort of a evolutionary incremental. We need to work how to prototype application interface. In the case of application development, you have two things. You have your front end and you have your backend. The front end is whatever the user sees. And the backend usually involve the databases and sometimes limited we are as well. If you did not get their functionality right, no amount of design UI and UX could solve the issue. So focus on the functionality, not the interface or the experience. Those come later down the road. Now the front end also divided into two segments. You have the visible segment. This is the design elements and the look and feel of the site, usually done by a graphic designer. And you have the invisible elements. This is the coding of the upside traditionally done by a programmer. So this is a team effort. This is not only a single person job in microscale, sometimes a single person or a single programmer can take the responsibility of building the interface, the webserver, the middle where the database and the user experience as well. But this is rarely the case. At least you have stream, someone responsible for the user interface and user experience. You have someone responsible for the front end and you have someone responsible for the back. And sometimes you will have someone senior in the team or doing what's called a full-stack design or a full-stack programming. They understand different layers and they can interact with each other. Developing user interface first will assist you later on developing the clauses and the information's needed. Because the interface is very clearly define what information the end user or customer expect to be displayed and captures. I cannot count the times when a customer asks for a symbol button that will do something simple from the customer point of view, but it turned out to be a nightmare for the development team. So always get the application and bottles are correctly at the beginning and agree that no changes will be made to this interface. Included Insert Design, and the requirement document to perform this process of prototyping the interface, you have to follow through a specific steps to make it a simplest possible. The first step, the sitemap, you have to build a site map. This is exit attracted forms requirements you got earlier. This is only exist to have some starting point. The sitemap is usually changed as you go along. The step after that is a non-visual prototype. It is initial capture of the screen requirement. You might even adjust the sitemap based on the feedback. You jump between this step and the sitemap several times. Before you move ahead, you keep adding screens and change the sitemap until no more adjustment required. Next, you have your wireframes. You define each screen in more precise way using some drawing application. And finally, you have your MOOC design. The reason behind it is to show how you will jump between screens and how it will function. You could do it with wireframes or assemble photos from a stock photo site if you wish. So let's start with sitemap. Before building any prototype, you need to create a sitemap, what screen, which screens. This will allow you to determine how many screens that are required in the application. The site map is created based on the initial understanding of the requirement and it's refined over time to build it initially, get the requirement list and highlight two main requests. The first request is the input requirement. This is a capture information. This is the user required to insert some data. For example, please insert your username and password. Next you have your output requirement. What the user is expecting to see or what they were expecting be displayed on the screen. Once you determine these requirements, grouped them into screens. Please note that usually not a very good idea to have captured and display screen. On one screen, it is used to be okay, but with the size of mobile screens, it is better to make different screens initially. So you'll have your initial sitemap, you have home, you will have third requested status profile, and you will have your subtree ends the next levels and you keep building the sitemap until you finalize all your requirements to be mapped to one specific screen or another. Once you are finished with the sitemap, you proceed to non-visual prototype. Before you start building the visuals. Before you start building the visuals, you plan on blank peoples. Without any interface, you get a sticky note during your meeting with a customer or a user and sketch it, or ask them to sketch it. This is 0. Designers skills. Don't try to make it fancy. Don't try to make it attractive. You are just sketching things on a sticky note. That's it. As simple as that. The benefit of this prototype, that it's real time, you can develop it with the user to get the feedback immediately. This will highlight lots of missing or unclear areas in the requirement. It is expected to update the site map and the requirement lists after this step. The next step you have wireframes. In wireframes, the final look and feel will start to show up in black and white, of course. And without graphics. In this stage, ignore forms and ignore colors. Because adding forms and colors to the mix usually shift the conversation from the functionality to the color and which one will look better. Your primary concern as this step is to look the location created in the non-visual prototype step. So you will have a bunch of sketches created by you and created by the end-user to look locations in each and every input or Display area, for example, the location of the search fields, the location of the logo, the location or the username, the location of the actual application itself, whatever input or output displayed. This is to ensure that every screen and every clickable item is agreed on. These mockups should not take more than an hour or so to make. So in a single day, you should have about ten to 20 variations for each page. It is a basic non-functional representation of the product. It is used very early on the requirement gathering phase. It is lacking lots of the design elements and some even don't consider it appropriate, right? Queer with the extra present, the photo, clickable elements or a bottom. And the gray boxes represent the text. Using the above simple elements. You can easily with the stakeholders, shoots him something to articulate what they like and what they dislike. The simplest way to do wireframes, if you cannot draw, is to build the grid on a presentation slide like PowerPoint or a similar application. You start by getting the website or an application similar to the one you are trying to develop. And snap a grid to xhat to ensure the proportions are correct. After you snap the grid, you can delete the older photo and all you have is now a grid. Start working on it. You can start adjusting the frame to match whatever you think. As mentioned, this is usually a discovery process. So you should experiment with lots of these to reach the design you think is the best fit for you. You only do this process to avoid starting with a blank sheet. Because for some people, it's quite a challenging to start this way. But offering them a blank frame, you don't mention what is based on what is the website or application you are getting. This blank frame from. It will generate a better results and more variations and variations. It's your friend, denser stage, copying another application layout, lowest safe. It is completely on recommended because it will make you fall into the generic trap, which means the website or application is already lost. So you have to have a differentiator. Don't Jacobian layout. Start with a template or some other website and develop your own. If it looks like other websites, then so be it. But if it's not, then you will have created something new. And set is a key differentiator. If you have different value proposition, your value and the competitive edge will drive the interface and the experience to be different. But if you found out after all of that, you have a similar application or a site to your competitors, then you need to rethink your value add and have more in-depth discussion with your business side to show the value more clearly on the application or recite. This is usually happen if you are developing application from scratch. If you have off-the-shelf application, this is not a big deal and you can simply ignore it because at the end of the day, it's off-the-shelf application. You can use wireframes to demonstrate the beaches and how they link to each other. But I would recommend deciding on the beach, look and feel before mapping the beaches to each other. And finally, we have MOC design. It is the screens of the application and how they interconnect with each other. This is different from the sitemap because this requires the visuals as well. You usually have two types of screens. You have. The input screen, as mentioned earlier, is used to input data. This is a capture and you have your display screen is used to display data. You start with the login screens. This is the first the input screen and homepage of your application. And each element of the Home screen can lead to another page and so on until you map out your entire application, it gets more complicated than that. But this is the initial idea. And on each of the screens, you should link it back to one on icon on the home screen. You consider the application simple. If it includes blow 30 screens and is complex if it has EG blah screens, your next step is to decide on your presentation tools. The best way to design more complex prototypes is by using special software to do this, you can create and link pages to each other to simulate a functioning gap. This software will make some sort of a digital prototype for you. Alternatively, you can do it in a manual format by printing out screen and simulate as if the user is pressing on a button on it. It's a bit of a learning curve for the user to understand. They are actually pressing a button on a paper and the screen is change on a paper as well. At this point, I have to say a warning. If you design it to well, the customer would think that application or a website is ready to always sit expectations so that it only mentioned that this is only a designed for the interface. One of the most common tool for the wireframes is called balsamiq. It is properly is the easiest one to use when creating wireframes. And it's not that expensive. If you wish to link screens to create some sort of an interaction and digital prototype, envision is your friend. It is easy to use and generate models. The most feature-rich application out there in this area is Adobe XD. But there's a downside. It's requires some design skills to operate it. Unlike the other two that Balsamiq and the Envision. Thank you for watching and see you in the next video. 5. Prototype's Best Practices: Now we move on to general best practices. And the first one of these general best practices are the templates. You can always use a template, but always considered the template as a starting point because it's familiar and content agnostic, but always consider it as only a starting point. You should plan to adjust it to fit your content. Next, we have responsive design. Responsive design is the ability to adapt to, to display screen. For example, the upside might have three columns on a PC, but only two on a tablet and maybe only one column on a film that design changes and adapt based on the device screen. We have also information design is a way you've presenting lots of data in an easy to understand format. This is used typically for a web sites whose loss of information or a very complicated reports. Unfortunately, this one is based on the prototype you will have. You have to experiment to seize the best feedback from users. It's based on your data type and the content of volume. Now, so what is qualifies as an excellent user interface? In order to get excellent user interface, you should be following what's called heuristic evaluation. You will find many temporalis to follow online. But every screen should pause the following checklist. Something familiar. It is something that users are used to in their day-to-day lives and know how to operate. For example, if you twist a door knob, then most probably the door will open. So the same concept will apply to website or to an application. If you twist it, it's expected to work or to function as expected. Same for the three dashes. Whenever you click on them, you will have a menu. So this is something familiar. Next, you have action feedback. Whenever you are doing something feedback NAS happened. This is the loading screen, the loading circle. This is the action or feedback or whatever you are logging, you will see a message. Thank you for logging on. You have to have a consistency across all systems. If a button look, look announcer bottom, it should function the same way. The same applies to color an icon. For example, if you have a magnifying glass, it should mean a search bottom and everywhere in your application, it should means the same thing. It cannot mean search in one screen and mean magnify and another screen. You have to pick one or another. It needs also to be intuitive and straight forward. It should not need special training to be able to use it. What will breed it? If this is not possible, it should have a few interactions to learn how it works, undo, redo and auto save. The user needs to feel safe and no action will impact him or her without a final confirmation. And if they make a mistake, they can always go back and fix it. Also, they use or need to have the ability to stop working at any given time and resume from that point forward without the need to fill everything. Again, this is very common practice in forums, filling online specifically, if a user fill like 50% of a long form, they expected. Or to save n The expected, if they press something wrong, they will not throw them back to the beginning of the process. So you have to take care of that as well. You have to also use a familiar language for the user. Tried to use the user language, not the technical language. You have also to make it clean and functional design. If the design is not functional, for example, if it has flashing screens that distracting the user, or too many elements in one screen, very tightly grouped together to the point that the user have to press on the screen back and forth many times to reach a specific bottom, then this design is not clean or functional. You should also give the user freedom. This is to give the user the ability to move in any direction of the application, forward, backward, and save flexibility. The application should be flexible and allow the user to adjust things, as you will see it fit. Like the ability to customize the interface as they see fit. For example, someone might be right-handed or left-handed. So they might change things a little bit differently to reach it anymore, Foster and accessible way recognition over recall, the user should know what the function is when he or she sees as without the need to reference manual. So once we see it, they know how to operate it. For example, the simplest one is a bottom. They see a button, they press it. Although that when you press a button on a screen, nothing happened. You're only touching the screen. But this is a recognition that we already have over a longer period of time that we, whenever we see a bottom, when I press it, something happen. Next we have Show Status. The application should choose a status like saving, routing ground thing or our grass. This is also part of the feedback. Whenever we are doing something, you should choose a status, not only loading, because if the user see loading going on and on and on and on, they might be tempted to refresh this screen because they might feel that the application hang on the background. But whenever you give a detailed status, mostly probably they user will wait for the application to finalize whatever action that application is doing on the back ground. Next, we have prevent errors. You should ask a questions to prevent errors like every user now expect a message to say, do you wish to continue or do you wish to cancel? This? Avoid deleting the user work by mistake. You have to ask for one or more confirmation questions. No user expect if they pressed canceled by mistakes at the application will take their response immediately and cancel every action they make already. For every input they made, they are expecting that you will give a plump it. Are you sure? And maybe one or two are you showed before actually canceling and deleting that war without saving. Same happens when you are, whenever you are trying to close an application, they are expecting to have some sort of a feedback or an auto saved mechanism. And lastly, you have to gray out, I'm available options early on. Don't offer users options that will give error a bit down the process. For example, if you are trying to book a flight tickets or are trying to book a hotel room, or VR shrank to book almost anything. Don't allow booking over time slot that is unavailable. If the time slot is unavailable, don't that user click it and then N23 screens and downstream they will get an error. Sorry, this time is unavailable. Please go back and select another timeframe. This adjust bad user experience. So you have to prevent that by green outdone available time slots at the beginning of the process. Thank you for your time and see you in the next lecture. 6. Prototype's Testing and Feedback: In this lecture, we will talk about prototype testing and prototyping. It's always quantity over quality. Produce fast regardless of quality, and learn from the mistakes. And the mistakes you did will accumulate quickly to present the progress and the hockey stick curve, starting gradually, very, very slow. And then suddenly you will have everything clicking and going upward the very fast. If you focus on quality, you will produce one or two prototypes and will not learn as much. Now you can put a formal prototyping in two ways. These are serial prototyping or barrel prototyping. Try to mix both to maximize efficiency. You can start with lots of battle prototypes. Each team member should provide one at least and show them to the end users. Your next step is to start to collecting feedback and which ones user liked better and why? Over time, try to incorporate all of these elements into one branch and bound for more complex serial prototyping. Let's take an example. You will have round one of prototype consists of five prototypes. Each one of them will have its own feedback. You will incorporate all of them into one prototype. And then you collect feedback. Based on that, you will create three more in round tool, but a little prototypes. And then you collect from all three the actual feedback and then you will proceed to the three serial prototypes. Each of them are sophisticated in its own way or different in its own way based on the feedback or liquid. So you will start like a reverse pyramid, upside down and do a lot of simple prototypes, like non-visual prototype things are beginnings are one that we mentioned earlier, AMD paper prototypes. And then you will start going to cereal. You will start going to native prototypes and actual doing MVP. The critical part about having multiple prototypes is separating your ego from the actual feedback you will get. If you have one idea, then it becomes your baby and you don't take criticizing it easily. But if you have multiple ideas, you can, they're more. As you become inclusive of all feedback, you can always generate more ideas by asking the team to contribute to the concept before it becomes the main branch of the prototype. Next we move to predicting feedback. How many should you include in your prototype testing? To get there? The more feedback you will discover. It's accepted for a 70 to 80% of the issues to be discovered, the relaunch. This mean that you will have around 20% to 30% of the issues discovered after going life, which is okay. But the symmetric of course, on time, the golden number is three to seven testers. After that, that discovered the issue is particular to a specific group of users or a specific use case. So you need three to seven testers. And in order to discover the majority of the issues in your systems, you are scoring agonist is a general best practices mentioned earlier. With each district, you give the machine or the heuristic evaluation template and let them score and leave comments. You will let them fill this form for every screen if they have a command, of course, sometimes you simply don't have feedback on that specific screen. You're going to have to use all dimension the items on the best practices. You can only use the things that matters to you. You can also rewrite the name represents something the user can understand easily. For example, don't write something familiar to the end-user, but you can write, Did you find trouble understanding the bottoms? You find trouble understanding the icon. We need to rewrite it using the user language. Once a user finished filling all the forms, and once you finish all the tests, you start listing the commence and which feature and step this happened the end. Don't forget. You also writing comments about the user action. For example, if you sell our user hesitation on a specific screen or anything you noticed during a test. For example, if the user started looking at a screen a bit of time, I don't know how to navigate or to move forward or backward. This means that this screen, I need a little bit of adjustment to make it simpler for the user and make it more user-friendly. Now, don't conflict this with user acceptance testing. These doctors mentioned earlier, just three to seven testers don't have a script to follow. You just present a screen and very brief about the application. For example, one sentence or paragraph like we are doing ride sharing application. And once you introduce application and you showed the first screen, and either in paper prototype, you would pretend they are clicking through it freely. So you give them the first paper. And they will simulate as if they are pressing the button. And then you give them the screen that there's a specific button or the specific link lead to the next option. You give them a link on a device if you made a digital prototype or our MVP, if they notice something in one of the screen, it will be marked as mentioned earlier in the review sheets. But the general idea is to let the testers play and test the experience in a very free-form. You don't control it whatsoever. If it leads to error, then it's fine. It's leading to errors. So the Final Thoughts on prototyping, do you have to worry about all of this from the start? The answer is yes and no. This is just a tool in your toolkit to develop a better application. Since most of the changes happen in the interface layer, it's good to lock these requirements early on. In other words, it is not an official Ba responsibility, both simple and will help you a great deal. So my advice is, if you can do something from the beginning I tried to do with, if not, try to stick at least to the templates and evolve. From this point, the UX designer usually goes beyond what's discussed here. But these are the fundamental elements. That means definition to have a smooth delivery of the application. Later on, things like navigation, bottom sidebars and minue position are explored more with a UX designer of the system. If you have a UI UX designer, this will be great. But if you don't, and this is unfortunately the case in many companies, usually what is discussed here can at least make you design a better application or a website. And as mentioned earlier, this is probably one of the most areas that keep getting a change request from the customer after he delivered the application. We need the sidebar bigger. We need specific bottom change. We need to add a specific function here on this specific interface. So it's very good to locate early on. Thank you for your time and see you in the next video. 7. UML Introduction: You have a list of requirements. And regardless of your development methodology, waterfall or agile, documentation is required to understand the progress of the application. And it is also needed for any future development or a change to the system. When it comes to documentations, There are two possibilities I had seen over the years. One, you are a business analyst with little coding or non-coding skills to you other developer with experienced coding skills, which one are you will impact the design module. The business analyst would like it to be video lightweight, while the developer will want it to be very verbose. They UML is an overlapping area between both the developer and the BAA. Lower still, there is a big difference when it comes to drawing details. Still, the overall idea should be understandable for both as a BA. Start with lightweight version of the diagrams and during the project. To develop or adds unnecessary details of those diagrams, it is not required to add all of these details at the beginning of the project. You start with a businesses skeleton to ensure that the business users understand it as well. And then handed over to the developer to adds unnecessary details. The same applies if you are a developer. When developing these diagrams, please start with the basic business language. But please don't do technical and tried to explain it to business. Trying to explain glosses, attributes, operations, message types, and return values are considered very technical topics. The business user will be lost and they might agree to something they don't understand clearly. And if this happens, you will be getting a change request after another or wars, the customer will not accept the project. So always start with the basic language. And once you will get agreement, feel free to add the technical language and the documentation you require. So UML, is it a standard or a bestow practices? They omega L is a language made to that. Diagrams have asserting common baseline. For example, it the same as a hotel ranking a five-star hotel mean you have a certain things and certain services additional to what a four-star hotels will have. But this doesn't mean that all five-star hotels or the same, same for the UML. You have a baseline or a foundation, you are building on it. But you can adjust and tweak things a bit to make it fit your situation. Please don't fall victim to treating your mail as a standard, like an ICU or an a PCI as ten, must be a certain way. It is not flexible to change. The UML is not like that. You can take the base UML diagram. Start adding component or adjusted whatever you feel. Logical situation. After all, UML is not frequently updated as programming languages or as the business use cases based on your situation, it's better for you to adjust it. Whatever you think will fit your situation best. So let's go with having an overall UML overview. Uml stands for Unified Modelling Language. Uml is an modelling language that has set of diagrams. It can be used universally across mini-projects, mainly software development. But it is not only for software development, you can use it as well. For circuit diagrams, you can use it and several other related projects. It is not a language dependent, which mean it is not based on a specific programming language. It's used across many object-oriented languages. When we use the word model, usually we mean a representation of something. This representation can be abstracted or very detailed based on which model you use. It can be representative of one part or the overall. Again, it will be based on which type of model you will use. This is why you are Mill, has many types, all of them and do the same thing, slightly different way. So why do we need a model to begin with? A model is required for three main reasons. Building consensus on what the project or software will look like and remove personal assumptions. So this one is to ensure that you have a better understanding of what's required and what is the final product should function and look like, document a complex system and show different aspects of the system. And finally, this tout, potential systems interactions without actually developing zany did quote, it is considered form of prototypes. You can then use the UML models in three main things. Visualize a project, prototype, project, and document the project. There is a fourth one, which is troubleshooter project, but typically rarely used during the actual project, the development, but you still can use UML and application troubleshooting. This means it is not a development method and it's for everyone to be able to visualize. It can be used on any system, software or otherwise. A physical system can also have a UML. The word universal minute has a common ground, some assumptions and some definitions so that anyone who reads it can understand it clearly. This is sometimes referred to as conceptual model that just contained the items and the relationship. The UML diagram may consist of an actor, processes, clauses, or functions that are being carried out. A UML diagram helps us software engineers to understand better a system or an application they are developing and documentation of the software or a system application. Uml diagrams play a crucial role. As a developer or a programmer gets the idea of the software application they are going to develop. The use of UML has proven to be highly significant in modelling and development of complex systems. Uml is a visual representation of a system that is going to be developed. It helps the client and the developer to understand the error or bugs in the application as well. For many software companies, the strategic cost of software increases. And with that time to develop the software also increases. To reduce coast on time issue. The UML can be used to reduce the reward and that region. One other use of UML is analysis of the problem. As mentioned earlier, if you have a software issue but you don't understand where they're coming from. Mel can help in that as well. One month I'd like you to consider because of the many charting vendor out there, they keep trying to differentiate themselves by inventing a new kind of diagram. So if you encountered some diagram you did not hear about before giving ourselves a few moments to search about it. Because across all diagrams, the shapes and connections are almost the same. So if you just look at it, you will understand it correctly. So don't be intimidated by how many you will have. At the end. They all boil down to the same thing. Thank you for your time and see you in the next video. 8. UML Overview: So let's move to what types of Unified Modelling Language diagrams are available. There are many types of UML diagrams, but due to their function and structure, there are two major categories you have. First, the structural UML diagram. The structure UML diagram describe the inner structure of the system software. It represents that building components, the actors, users, and the part of the system. The structure or UML diagram shows the relationship between different clauses and the modules of the system. The primary concern of the structural UML diagram is to explain parts of the system, not how the system functions and behave. Let's take more clear example. In our example, let's have something simple, like a human foot. You haven't the human foot mini bones. But at very high level, you have seven of them. Each one of them are named, decremented and very clear. Now we know the building block of the foot, but you don't know what you can and cannot do with these elements with these bones mentioned, you only see the static view of the components of the foot and you can see how they fit. This is the structural UML diagram. Next, we move to behavioral UML diagram, like the previous example. These are the diagrams that explain how you can move the foot. Now we know the components from the structural UML diagram. Now in the behavior, you know how to use these components, what you can and cannot do with these components. Each diagram explains certain aspects, like how things connect while moving, or the possibilities and range of movement. As you would have guessed, these are in the 100 range. Seemed for a complex system, you would have hundreds of options to depict the possibilities of the system. You can cheat when creating these diagrams. You can do this by making the system less flexible and reducing both the parts and the possibilities. As you develop, you add details to make it more flexible. For example, start with a wooden puppet was limited range of possibilities and add details as you move along. This is to reduce the overwhelming feeling you will get beginning of the project and allow you to create an MVP. Creating an MVP will make the direction for the development clearer and very obvious. We have one last category. It is not actually accurate. You agree it's more of an elements. This is the informational and packaging elements through those, this is not a diagram by itself, but it used across many diagrams. These are things like packages of multiple elements, structural and behavioral, or notes on existing diagrams. Now the obvious question which comes first, the structural or the behavior diagrams, you probably know the answer. Both will impact each other, but tried to make it some sort of an spiral format. One of each to avoid running out of time because you allow too much time for one type over the other. So let's start by having an overview for the different structural UML diagram that show a static view. First, in the structure of UML diagram, we have a class diagram. Our class diagram show a set of objects that are interacting with each other in a clause. Mostly glass diagrams are linked with real life Object-Oriented Systems, composite structure diagrams. This diagram is similar to the class diagram, but then instead of showing the whole clause, it shows the individual parts. It represents the internal structure of any clause. We have the deployment diagram, the static physical system. The hardware software relation is described. Using this diagram. We have packaged diagram, the Becker diagram portrays that dependency among various packages. It shows multiple layers of the system. You have object diagram. The instances of a class diagrams are shown in the object diagram. It shows a particular instance at a specific moment, it is closely linked with the losses of the system. You have the component diagram. A component diagram shows the how different components of the system are linked together to form a network. It is also show that dependency among different parts of a more extensive system. And lastly, you have the profile diagram. This is the meta data that will fall diagram shows the relation between a specific stereotypes. Existing UML notations can be extended using the specific stereotypes. Next we move to behavioral UML diagrams. So these orders at different behavioral diagram that shows the dynamic behavior. The first one and the most common one and the most popular one as well is the use case diagram. Use case diagram is used to represent the dynamic event in a system. It includes the actors or the users that are handling system. It may not be in sequence, but it's visually represents that how the system works and how the user interacts with the system. There can be multiple user and actors and a single use case diagram. We have also activity diagram. Activity diagram show how the activities are linked together to present the services at various level of abstraction. The activity diagram is just like a flowchart describing a different series of events in the system. You have the state machine diagram or in short, state diagram. And this diagram shows various states of any application or software. Different component of the system are represented in a state machine diagram. This unit of action from entry to exit is shown in a state diagram. We have also another popular one, hold sequence diagram. As stated by its name, a sequence diagram represents a sequence of events that occur between the user and the objects. It is one of the most significant popular UML diagram used in computer science. You have also communication diagram, and as opposed, it used to be called a collaborative diagram. As depicted by its name, the communication diagram shows the communications among the different objects of the system. You have also interaction overview diagram. And this diagram control flow ends the interaction overview diagram is shown by its node. The notion that are used in the interaction overview diagram are similar to the sequence diagram. And lastly, you have timing diagram. The focal point of the timing diagram is the timing constraints. It shows the interaction between the different objects or the systems during a specific period. So which diagram should use? The short answer is the one that will be used and understood. Lee, by the business side and the development side. Uml has 14 types of modals. Not all of them are necessary to code the application. So select the best for you and your situation. At least you create three or four of these diagrams. Building the models is quite time-consuming. What it required even in agile development method, because without them, you can decide on the direction of your development effort. So why bother with 14 bigrams? Why not create the two obvious one, the cloth and the use case? Because each of this diagram is considered some sort of a simple prototype. Each one sees the system a little bit differently. Each of them expand your understanding over different system areas. For example, the timing diagram will make you consider the duration of the object will be held in memory, and the load time when any given server. The deployment diagram will make your deployment with the system engineers as simple as possible. The communication diagram will make your life much easier with the security team. Because now they understand which system is talking to, which system and why. The sequence diagram will make your life much easier with the business and the governance team. The component and package could also help you design the containers of the application. For example, if you are planning to use containers for application deployment, this is the case or similar application cluster deployment. The return that value is high from all of these diagrams was a challenge. I always saw. It's time. You don't have time to do all of them. As mentioned, each diagram target a specific something and they vary in the type of details because of the same reason the audience for them is different. The common mistake that usually cause lots of issues is that one creating the diagram is the development team acting as business analyst as well. The dev team is usually interest into technical diagrams like for example, class object and use cases. Or they simply plugged in way too many technical information into the business diagrams. Diagrams should be very simple. The primary objective of these diagrams is to get others on board the software project. So you have to be aware of the software operational stakeholders. Thank you for watching, and I'll see you in the next video. 9. Software operations Stakeholders: Now we move to software operation stakeholders. In any given software, you have the following audience that would be interested in your software. The first group will be the obvious one, the business team. This is a group responsible for the rules and the business overall and the flow of the process. You have also got the vault 14. You cannot miss those obvious ones. How they will do all the requests. And we put in two lines of code. You have the system Engineers team. How would they will deploy this quote and two servers while maintaining the performance of the servers from the aspect of resources, if you are lucky, you will having a DevOps rule in your organization and in this role doesn't exist for you. You have also the security team, how to secure its application. You have the GRC team houses, meet the legal requirements and reducing the risk of specific software. You have also the network team, the communications, the bandwidth requirement of this application. And you have the UR UX team, how it will be user-friendly and enhance the user experience while maintaining the branding of the organization. If you can, please create the diagrams, but if you cannot do that, you need at least the following to develop an application. Load than deployment roadmap will not be the best case. And you will have lots of explanation to, due to the previous stakeholders. You will have at least some starting ground. You will have three levels of diagram nested on top of each other. You have first the core diagram. Without those, you cannot develop the application. Next you have additional diagrams. These diagrams are explaining specific aspect of the software and you should do them if time allows. And finally, you have extra diagram. This diagram are necessary as well, but their use is specific to a specific use case, which mean it's case-by-case use based on what application you are trying to develop. So you will use them as needed only. So now we know which Diagrams to draw and how to prioritize them. So what are the tools to draw the UML diagrams? The tool will make your life a bit more organized and it will speed up the drawing process. But creating auto connection, for example, the pre-made shapes as well. Drawing everything from scratch will be a long process, but I would like to highlight to you, it's done only once. So you create your drawing only once, and then you will start to reuse them over and over and over. So whatever tool you have, you will get used to it. If you can get a premium drawing too, like a bait version of this obeyed version of Visual Paradigm. For any similar tool, this will allow you to draw privately and commercially. If you are using the tool for studying, you can use several tools like yield graph editor, human, visual paradigm, Community Edition, or even paying for your drawing. All tools you can get easily online, but it's limited to private use. And you need to check the tools, documentation if you can use them for business and commercial usage or not. Thank you for your time and see you in the next video. 10. Class Diagram: First, let's discuss two main diagrams, the class diagram and the use case diagram. Both are considered core diagrams. You cannot build the software without them. So first, let's start with class diagram, UML class diagram is used to giving an overall a sketch of a software system by assuming the clauses, attributes, operations, and the relationship between them. It consists of three main parts, className, attributes, and operations. It plays an important role in software application development by helping in constructing the code. Diagram gives you an idea about the type of objects exist in the system and the relationship that they have with each other. You can consider a clause as a group of characteristics that define a specific set of data processing system. It offers a high level view of an application. This middling methodology applies to almost all object-oriented methods. So why do you need a class diagram is a case of a monolithic application. We're both applications and data access logic or combined inside the user interface they use over the class diagram is almost 0. However, the software developers of today have shifted toward the component-based application that have the flexibility to be maintained, extended, and scaled from the desktop to the cloud. These types of applications require the creation of clauses with boundary and a balanced distribution of responsibility. This is where a class boundaries can help. It helps you to design your classes, which become the building blocks of your application. Class diagrams enable you to document the structure, operations, and attributes of glosses. They also play an essential role of understanding the relationship between glosses, inheritance, hierarchies, and responsibilities of entities that provides a system behavior. The primary usage of class diagram is system design. You have multiple classes, but nowadays, most application already have the classification breed made. Or you can easily find them online. Which mean in most cases, you will have most things defined for you and you only have to reference them in your class diagram. You might be wondering, why should I bother with a class diagram. As mentioned earlier, a class diagram is a blending tool just to ensure you prototype your classes and application layout correctly. It forces you to think about clauses and even tried to reduce it. As mentioned, some tools allow you to generate many clauses with a very simple steps, but this will result in publication in code. And it's just bad practice. And if you do that, you might even have to do code refactoring to solve the issue. Think of it as creating a separate menu clause. For each menu you will have how much it duplicated code will be there. The same issue will happen if you create a few classification. One clause of code might get way too much power over others, and this is not good as well. This is why you need a class diagram to do the minimum possible clauses while having a good code. So what are the bruise on columns of Class Diagram? You have on the bra side, you have class diagrams provide a blueprint of the application or software. Programmer is going to structure. It makes the coding easy. It builds a roadmap for the developer. It shows the instances and the function of a class on the downside on understanding and class diagram require knowledge of the class diagram. This is a technical diagram, not for a business user. It gets difficult to understand the class diagram. If the software application has many clauses, it takes much time to draw a class diagram. So what are the parts of the class diagram? The vital elements of a UML class diagrams are className, attributes and operations. Let's start by class name, and this is the name written segment. A clause is a blueprint of object which can share the same semantics, relationship, operations and attributes with a gloss is portrayed as rectangle that consists of a name, attributes, and operations in their respective compartments or parks are books with three partition that present the class and a class diagram. These partition should include. First, then remove the cloth in the teleportation. Attributes, sometimes also called variables, usually in the middle partition and possible operations or functionalities of this specific gloss This is associated with the class will be on the bottom partition. Next we move to attributes. Attributes a named the property of a clause which explains the object being modeled. For example, your name and age are attributes of yourself. The only define things so that you can identify yourself from the person next to you. If all elements have the same attributes, it's okay to remove it because it will be null and waste of data space. It is placed in the compartment below the class name. And attribute that is computed from other attributes is called a derived attribute. For example, if you give me your birthday, I don't have to ask you for your H as it can be computed easily. So H, in this case, it's called a derived attributes. Here are some characteristics of attributes. They are usually written long with visibility factors. The accessibility of an attribute of a clause is described by its visibility. The names of attribute should be meaningful. So what are the visibility? The four visibilities that are available are public, private, protected and packaged. They are donated. Blood bound and delta signs respectively. These are the signs in front of the attributes. They define the visibility of such attribute. Who can seize a specific attributes? Is it only local and specific clause or someone else can read it or write it as well. The private sign means this is a private attributes. No one else can access it, like employee Social Security number. The public attribute means something publicly, any other clause can access. In this case, maybe the photo and the email might be bubbling. And okay to see by everyone as a hash mean, it's protected, which means it can be accessed by the same class or a subclass. Like an odd example, you need to make the group or department have visibility on the employee photo, but no other department can see the photo. In this case, you make it protected. Lastly, you have the tilda, which mean the package. The other parts in this layer of the application. So usually you group multiple elements inside the package that bigger than a clause, maybe multiple classes or even multiple components as well. So in this case, whatever in the boundary of this package, See this specific attributes. Another example of visibility, if we assume you are a clause as bare our previous example, the private sign means a confidential information you don't wish to share with others, like your password, for example, your credit card number. The public means singles. You are okay to share with anyone who doesn't know you. These are things like your height says, anyone who can see you can determine it. Bitcoins public. Next you have the protected, it means something that you want people around you to know it, but you don't wish everyone to know it. This could be your first name and your last name. The tilda mean one step bigger, like your community knowing your firstname only or your last name only. Now for the attribute left-side, you should specify the data types. The most common are you have integer, this is a positive number. You have floating point number, a number, but it's used only when number accounting in millions. Numbers like how many kilometer or miles between our sun, the sun. This is simplify numbers by removing a specific base to making ten zeros, one Boynton zeros, 1.01 to the power of ten x or 15 x to the power of N. To do a simple calculations. You have also characters usually used to make the data cleaner and rarely used. You have string, traditional sequence of characters, usually up to 255 characters and you have lost one is Boolean condition. This is yes-no, true-false, 0-1, red, yellow, or any two data possibilities. Two things I want you to note in the mp3 example. Therefore, number is a string integer because most forms have 0 to start. And as mentioned, usually some system or Mesos if the 0 on the left side of the number. So feel free to try it two with 0 or without 0 to try it as a string or as anterior. Under operation, there is two columns. This will be expanded later with other values and variables from the development team. It is common practice to leave it blank like that. The operations, the capability of the class to change defined attributes. I think of it as the boundaries of control. For example, you can change and control your name and your phone number, but you cannot change your height. You can also select the name of your children. This is a child, the clause, you can choose your car. This is another clause. And administrator, for example, can sit the buzzword. And this is another example of a class impacting and influencing another clause. The finding operation is a control within this gloss or by this clause impacting other clauses. Please note that both operation and attributes start with a lowercase letters. So what are the relationship in the class diagram? Glosses are interconnected with each other in a specific way. There are many different types of connections. Here are some of the most common ones you will be using to build the class diagram. The first relationship is association relationship. Association is a broad term that is used to encompass just about any logical connection or relationship between clauses consists of this connection is the fundamental connection. An example is a block and a wall linked together. But as fusion connection does not show why they are connected, you can write it on the line to explain. Though, this is rarely used, you have direct association. The direct association is represented by a line, an arrowhead, and refer to a direction of a relationship. The arrowhead represents the container contains the directional flow. This is to avoid illogical situation in developing code. For example, you can build a world using multiple blocks, but you cannot build a block using multiple wall. This is a flow control mechanism that is typically used to allow flow in one direction. Next, you have reflexive association. Reflexive association occurs when a clause may have multiple responsibilities or functions. For example, a customer list in a database might be a potential customer, building targets, upselling lists, et cetera. Or a user might be an administrator and the customer at the same time. But because of the confusing nature of this association, it is not frequently used. You have also multiplicity. The number of elements in one clause in relation to another class is shown through multiplicity, which is an active logical association. For example, a car consist of multiple doors, while one core can have two or four doors, the range or the exact numbers of elements is shown next to the cloth. The option for that r, you have 0 to one. This is none or one. You have n, which represents a specific number. You have 0 to many. This is a range of from none to n, and you have one-to-many, which is arranged from one to n, and you have a to B, which is a specific range. This is a defined range. The next relationship we have is aggregation. Aggregation refer to creation of a specific clause because one clause being aggregated or built as a collection. For example, there is a class customer list that is made up of one or more customers. The relation between contain clauses and the container is weak in aggregation. In the above example, the customer will remain there even when the customer list was removed. We delete the Customer List, the customer will still be there. Aggregation is displayed by drawing a line from the cloth to the aggregated clause with a diamond shape on the aggregated clause site. And you have composition. The composition relationship and aggregation relationship are very similar with just a single difference in the relationship between contained the claws and the container class being strongly dependent, the container class will be eliminated when the container clause is destroyed. For example, a building block will also cease to exist once the wool is destroyed. Another example is the hotel and the lobby. The lobby cannot exist without the hotel. If you remove the hotel, you automatically remove the lobby as well. The composition is displayed through directional line connecting the two clauses and fill the diamond shape on the sides that is connecting to the container class. Next you have inheritance and generalization and inheritance origin realization show a type of relationship in which one associated clause is a child clause, while the other one is a beer underclass child. The clause consist of the same functions as a parent. Inheritance is shown through a solid line from the child class to the Santa Claus with an unfilled arrowhead. This mean, instead of copying the attributes and operations across clauses, you can just make them inherit the attributes from a barren superclass for an easier management and easier update later on. You can still add individual attributes to each of the children of the subclass. As mentioned in our previous example, your children will have the same capability as you common ones like name, age. They will have their own name and they will have their own age. But they also might have something to identify them that you don't have. The realization and implementation relationship. Realization relationship comes into action when an implementation of the functionality is defined in one clause by another clause. In other words, how to acquire the operations of that specific gloss realization can be shown with the help of a braking line. Having an unfilled arrowhead from a clause that defines the functionality of the cloth to the clause that implement that functionality. For example, a client ordering supplies from a supplier or a coffee request in a coffee shop. This means that request is moved to the supplier to be able to reform and execute the action, otherwise, nothing will happen. So let's have a close diagram example. The whole class diagram represent the layer of the system. One system could have many clauses. In our example, I will try to explain part of an online book shopping experience. You start your diagram by giving the claws and name and define its attributes. Just like our general example, you define the names of the major parts of your system. There is no right or wrong. You have to muster clauses. You have the catalog and you have the users. From the catalog, you have books, a clause under it as a child. Other clauses that should be in the diagram but not mentioned like what you book, magazines, et cetera. You have your users who have two types, admins and customers. Customers can create a shopping cart and favorites. Limitation is that the shopping cart and favorite can only relate to one customer, denoted by one on the relationship. One customer can have 0 or one shopping cart. A customer can register, but don't buy anything. A customer can have 0 or menu favorite lists, both shopping cart and favorites. There will be just one. But for the sake of the example, we can leave them on the unlimited. The relation of the favorites ends the shopping cart is composition because they cannot exist without the customers. On the other hand, there is a relationship between the favorite and the books as aggregate. If you notice, these are usually extracted directly from a business requirement. Because this is what usually happens. Because this is what usually happens. You take the requirements from the customer and highlights the clauses and what it should include and how they are related. Thank you for your time and see you in the next video. 11. Use Case Diagram: Use case diagram belongs to behavioral UML diagrams. These are dynamic in nature. A use case diagram describes and shows the relation between the actors and users and the system. There won't be a specific order and a use case diagram, the order of the steps to reach a goal cannot be seen in these diagrams. A use case diagram is quite simple and can be easily created. It consists of a few shapes and relations. I use cases, a high level description of the requirements. Each use case is a stand-alone activity. Why do we need the use case diagram? They use case diagram in the documentation of the system software helps the developer to have a better understanding of the system and user interaction. It displays system requirements and easy to understand manner. Moreover, use cases help to create statistic cases that are later used by software quality testing team. They use case diagram or like the blueprint of the software. It will shoot a major outer functions and it does not include the instances. It choose a dynamic behavior that is presented in the system software, like the blueprint of the system, it needs to be as simple as possible. The diagram identify the functions without digging deeper into the system. Drawing a use case diagram is quite simple. There are many online tools available with the help of which you can draw a use-case diagram. You can use Bain software on your laptop or even MS Word. So what are the pros and cons of use case diagrams? On the pro side, it's easy to create and use a use case diagram along technical person, a client can even understand them. It depicts the measure functionalities of the system. It shows the relation between different functions. It's easy to create prototypes or a mockups using use-case diagrams. And even the diagrams itself can be considered a very lightweight and prototype. On the negative side, on the con side, throwing a use case is time-consuming. It just shows the functionalities and not the instances of the system. It does not show the order of activities. So what are the parts of the use case diagram? Actors use case, system boundary and communication link. So let's start with system boundary. The boundary of the system is made up of tangle. The actors stay outside the boundaries of the system. That rectangle represents a limits of the system. It is used to define system parts and outside actors. Next we have actors. Actors in a use case diagram represent the users. And actor can be anyone ranging from the person who are using the software user or an admin, for example, to an external device or external organization. The role of the actor is to start the system. They need to give some input to the system to start working. However, there will be some actors who will expect output from the system. The actor is a human figure, is that interacts with the system. And actor is a group of similar users or organizations. It is not one specific person. It's an entire group of similar requirements and needs from the application. Usually, it's very simple drawing of a human based on the tool you will have, the shape will change, but usually it looked like a stick figure. Actors could be primary or secondary. The primary actors are the one initiating the action, and secondary ones are the ones reactant to that action. In the example of the online bookstore, the primary actor is a customer opening low website, and there's a country actor is the organization reacting and displaying the products available for the customer purchase. You could make the primary on one side and the secondary on the opposite side. There is no role for that. Next shape you have is use case g. Drooping use case is simple. It's an oval shape, represents the use cases. Every actor and user should be linked with a use case. Some other use cases are considered internal to the system and not linked to actors, but linked to different use cases. I use case is I toss the system should accomplish from the user point of view, not the developer side. Something like login is considered one use case displaying products are called Federal. Another use case. Usually use cases are dynamic and start with a verb like login, display, Add to Cart, favorite, et cetera. Each use case is considered a process that can be broken down further based on the complexity. If you are practicing a Gentile, you keep breaking them down until you reach user stories. So this is a very simple use case diagram. You have couple of actors, each of them connected to a specific use-case. So what are the relations? Mcus case, there are four types of relations. In the US case, you have Association, include extend and generalization. Association, a communication link between the actors and the use cases present outside the system boundary. It is a link with a straight solid line. Next you have include. They include tag used above the communication line in the use case diagram. They include relation is present among the different use cases. For example, the login use case must have Chick the possible, this means direct brings a login, will activate the buzzword use case as well. So if you have one use case Stringer and another in this case, this is include relationship. To show the include relationship using a dashed line with an arrow pointing to the included use cases. Sometimes it's called use use case. But personally I prefer include because use use case is a little bit confusing, the bees use case to rigorous it under all conditions. Its purpose is to simplify the bass use case and to make it smaller and allow the usage of a specific function across multiple use cases. And other words, whenever a user is trying to login, they will activate a validate possible. It is not some primes, it's all with relationship. So why not included in the login? Because the buzzword, the validation, might be required and other activities and other use cases across the system. You might need to validate buzzwords across many layers or our cross many use cases not only login. So in this case he separated into different use case. So that multiple use cases can include it as part of it. And this will simplify diagram significantly and we'll simplify the coding of the system. Next you have extend. The extent tag is used above the communication line. In a use case diagram, the extend relationship is used when a use case is sometimes happen only when a specific condition is met. For example, the display Wrong password, the error will not happen to every user every time. So it's considered an extend use case. In other words, the extended eg add a specialized behavior or action to obese, use keys like a prerequisite checker or registration form for the first time user. Next we have generalization and this special relationship. Two use cases. Take the input from one use case acting as a beer on to a child. This could be two different cases for the same action, like for example, payment using PayPal or credit card. The payment to self, it's the same, but how it's implemented is different. Same as our example. You could be placed an order on a store or is it pick it up yourself or ship it, your address. Use cases are mainly linked with the functionality of the system or the software. It's highly significant that the relation between different use cases is appropriately mentioned. So what are the use cases? Brecht says, what are the common practices when creating a use case diagram? These are not your mail requirements, but each of the use cases need to have the following. It needs to have meta. This is date created, updated by WHO and his name, et cetera, the actor or in some diagrams that's called an agent at description business rules, it should be include whatever business rules you have in your organization. Assumptions. If you have any preconditions, these artists conditions before they use case can be reformed as needed. Boost to condition the conditions that happen after the use cases, but reformed the steps from the pre-condition to the post-condition exceptions, why this use case might not work, and how to get around that. You have a special kind of use case, gold and negative case for each of the conditions and the steps, you should create a negative case. What if the user did something else? And this is step. For example, what if the user opened the login screen for five minutes and did not type a possible. Will it be still waiting? Or for example, it will look out. So this is in this case, a special use case created to secure more than application. This is very useful, especially in security. And each use case diagram should have a glossary to avoid conflict, always create a definition and abbreviation table that represents your meaning to the reader. This is a glossary. This is one of the ways to reduce conflict from misunderstanding. Also, use a clear, simple language. So what are the use case and user stories? Applying Use Cases and user stories are now something quite common. Especially with a giant practices. It's getting more and more focus. The use cases or something similar to user stories in our giant. But usually it's bigger than an adjoint story, but smaller than apec. So user stories are simple items. For example, you should fill in the blanks of person. I want to do something so that I can reach something. It should not be complicated or even longer than one sentence. It should be as simple as as the entry employee, I want the text to automatically move to the next box so that I can type continuously without using a mouse to click the text field. So now, let's move to use case example. We will be using our online store, the customer. In our example, we'll try to look in the association relation and he or she will get an access. Or if they use the wrong password, they will get a wrong password and display an error use-case. Once a customer logged in, they can displays a book listing. But before that, the availability is updated to show what's available and what's out of stock. This is a validation use case is on include relation, then the customer could add to favorites the book they like, even if it's out of the stock, but they can only add available book to the court. So the validation using the same validation use case is initiated to ensure that their stock available since they got the first display screen wells they added to the cart, they came close to the beach or proceed to place an order. Before placing the order, the system needs to preform a revalidation of the availability. And then the customer can either requests the pickup point or shipped to address. That's all for the use case diagrams. Thank you for watching and see you in the next video. 12. Sequence Diagram: Usually sequence and communication diagrams act as alternatives. Both explain almost the same thing. However, there's a sequence diagram is more popular. So let's start with sequence diagram. Sequence diagrams are used to show the sequences of interactions between the user and the actor. And the system. Sequence diagram on legs, a use case diagram shows the details of the operations or the process that are carried out. These diagram shows a timely auditor of interactions and the messages that are being sent to carry out the operation. A sequence diagram is an interaction diagram. It's one of the major and essential diagrams and software documentation. It allows the developer to understand the system requirements and the order the user is going to interact with the system. In other words, it shows a sequences of events in a particular use case and how it will flow. So why do you need a sequence diagram? The best part of this diagram is that it's chose the messages and the order of time when the user interacted with the system. Sequence diagram shows the overall system design and it's relatively easy to understand. The sequence diagrams start from the top and keep on descending as a messages are exchanged. A SQL diagram represents a logic behind the function or the operation. It shows the commands and messages that take place between different components of the software system. To avoid confusion, the term object is not the same object. And the object diagram, it says the steps they user or customer goes through to get the service. It is a larger building blocks. So what are the pros and cons of a sequence diagram? On the positive side, on the blue side, there's a real life application can be explored with a help of a sequence diagram. A client from a non-technical background can easily understands a sequence diagram. It is easy to maintain. Messages flow among different objects as they're presented in sequence diagram. Identify additional objects that were missing in the class diagram. On the negative side, on the con side, used to show a single stream, which mean a single use case. These diagrams becomes complex if there is too many lifelines. If a message order is changed, it can produce different results. It does not show the amount of time between interactions. So what are the parts of the sequence diagram? Sequence diagram consists of the following measure components, actor, lifeline, messages, arrow, activation bars, and finally comments. The sequence diagram has too many messages, types and parts. What I'm trying to achieve is to explain the core concepts to enable you to do whatever you wish with it. The first part is actor's actor. The entities that interact with the system by actually changing the data. An actor can be any user or any external hardware that interact with the system. The thermal actor is not specific to any physical entity, though. It depicted as usual by a stick figure or human muscle. It doesn't have to be a human, it could be another system. Next you have lifeline. Lifeline shows a separate contributor in an interaction. A rectangle followed by a dotted line represent the lifeline. This lifeline could be for an actor, object or even clause. The sequence diagram usually gets quite complicated based on what you are trying to achieve. But always remember, moving down the lifeline, mean more time is passing. Next you have messages, arrows, messages out, or the communication lines between different lifelines. That message is true. The operations invocation. In a sequence diagram, various messages are represented in a particular manner based on their functions. Usually is a messages follow a particular format. Though this is not mandatory, but it should be as shown. The first message we have is a core message. A simple call message is represented by an arrow that points to the Activision part of another lifeline. The messages can be any command that an actor sends. You have a return message. Returned message is a particular message is sent back to the colon. For example, if you are looking in to assist them and you enter a wrong password, I return the message will give the color wrong. Bosworth. Try again. You have also sulfur message itself. A message represents a message invocation in the same lifeline. This means that message will loop to the sender. This happens and errors. It shows a returning arrow if two objects inside the clause or talking to each other, and you were using clauses in the timeline, not objects. So as you can guess, this is a special use case. You have also in the sequence diagram what's called as alternative frames. Alternative frames are two choices between two messages sequences like yes, no, or valid and invalid. It will look like a frame box on the top of the Lifeline and messages. The top half of it represents the condition and the lower half represents anything else, the error case and a sequence diagram. You have also activation bars as thin rectangles represent an activation bars. It shows a time during the operation of an element is being performed, how long an object debris forming a specific process, Activision boards are added after mappings and messages between objects. Understand that duration. It takes an object to finish the process required. The bar start with the first transaction and ends with the last transaction. This sin rectangle is presented betweens the dotted lines of the Lifeline and lined up with the initiation and the completion time. The actors doesn't need an activation box after all the activated all the time because they are the one initiating the interaction. And last thing, the commence in a sequence diagram with the help of comments or notes, you can attach remarks to different elements. So let's have an example of a sequence diagram. So the first step is to list all objects. In the example of a website of a bookshop, we have for mean objects that the customer needs to get the desired results. You have the Website, the user interface. You have the company server to process the requests. You have the Security database to validate and store identity. You have the product database, the quarter of the website, and you have only one actor which is the customer. So first, you draw the lifelines of all objects, of all five objects. Now you list the steps the actor or a customer needs to get the required books. I'm simplifying the steps, but you can go deep as you need. So the steps to be listed on the customer opens the website, though upside, prepares response, the customer like something and tries to login. As mentioned earlier, each sequence diagram typically have only one use case. In our example here we have three steps. Opening the upside, preparing a response on the customer likes something and tries to login. This is x_ few Use Case. The first use case, we have the simplest steps need to be translated into messages and return messages. And finally, edit to the diagram. The first message we will have is opening go website to the website UI, and then the website you're I ask the backend to request the catalog and the web server itself request a product update forums or product databases. And the server supply to the website user interface, the catalog. And finally, the website displays this catalog to the customer. Once a customer sees a catalogues in, they decide they want to login, they submit their login information the upside best over to the server and the server validated with the Security database. Now, you have alternative frame. You have either the security credentials or the login information are correct or incorrect and kind of correct. It will do a return a message of correct. And the server will give us access to the website UI and the upside you, I will display look and success. And if else with a incorrect case, the server will give failure. And the website URL, we'll do a display login error. It's as simple as that. Thank you for watching and see you in the next video. 13. Communication Diagram: Now let's move on to communication diagram. A communication diagram is also used to be called a collaboration diagram, is a diagram that shows the interaction between an object and its associated parts. It shows the relationship between objects. So why do you need the communication diagram? It is a known fact that both communication diagram and sequence diagram or similar, both are equivalent in terms of presenting the same information. Communication diagrams are fringe elements that are in tune with space. While sequence diagram arranging elements that are in-tune with time, despite being used lists and sequence diagrams, communication diagram still have their uses. And then bigrams are great help in visualizing relationship between different objects when asked to perform a task. And particularly also, they are great help in determining the accuracy of a static model, a class diagram. So what are the pros and cons of communication diagram? On the positive side, it's o for better understanding of how components communicate and interact with each other. It has the flexibility to add new objects in two-dimensions. And on the negative side, it's more difficult to see the sequence of messages and it has fewer notation options. So what are the component of a communication diagram? The diagram have several elements. It has actors or user, use case, communication link, connector, symbol, and dotted lines that start with an actor. And the actor isn't communication diagram represent the use of this could be a customer or an employee. The actor role is to start the system. So by giving some input to the system, the process will begin. And usually it depicts by a stick figure. Next you have a use case. Use cases are represented by an oval or a square shape with a text included as well surface as a function of the system E2 transition leased from one use case, there's an x, and this continues until it reaches the end of the system process. Be a class or an object as well. It doesn't have to be a use case. Next, you have communication link. The communication link serves as a bind that connects the actor and the different use cases. And the diagram is a straight line. You have also the message symbol. The connector symbol consists of a straight line with an arrow attached to it. And some cases, it can be curved as well. It's just part of the transition process where it links with each use cases. The messages work in one way. There are no back and forth betweens the details of the interaction. It's only the primary interaction between objects. U3 is this messages using the numbers in the front of them. For example, a message is starting with one, and if this is hit another object, it become 1.1. not two. This will allow you to trace each unique message to its source. The only issue you need to figure out is how many messages bird track. For example, if one message hit 20 different clauses, you might need to make three branches to give it a clear vision. This is called creating a branch for messages, usually use the if you have some subprocess that will generate lots of messages that will not go outside of this process. In this case, you create a branch just to make things a bit clean, but it follows the same structure as if you are trying to build a numbering in a Word document. For example, you will have the initial request and you will create the sub items beneath it. We keep going on and on as if you are building a wall, the document also, if you have a message to the dissent at the same time, you give it the same number still, but you differentiate it with a letter. For example, it becomes one a dot 0, then it hits another node and it becomes one e dot. So you have also a special kind of message that is with guard condition. These are the messages that does not executed except in a specific use case. For example, if a equals b or a is bigger than b or something similar, and in this case, the message would happen, otherwise, the message you will not be sent. And lastly, you have a dotted line. A little line is only seen between the last use cases. The line is only seen between the use cases and it serves as a link between them that doesn't have any other function. Then an association link. Sometimes it's dotted line and sometimes it's solid based on what tool you are using to draw. This is Pacific diagram. So what are the relationship and the communication diagram? And so communication diagram them in relationship found would be between use-cases themselves. The interaction between the use cases is the focus. The actors and the use cases have a relationship as well, but it is not the primary focus. The relationship between the different use cases have an overall impact on how the diagram can be explained and received. So let's have an example of a communication background. Let's take an example of an online bookshop where users can search the inventory on order any books or line specific to this particular store. The first step is to list the objects. In our example, we have four main objects the customer need to get the desired results. You have the Website, the user interface, you have the company server for groceries requests. You have the security of the database to validate the store identity, and you have the product that is, this is the core of the upside. And you have only one actor, which is the customer. In this diagram, the actor initiate the action by opening the website. And once it happens that website you, I request a catalog from domain server. And the server forwards this request to the product database to check if there was a catalog update. Next action, the user tries to login to the website. The website, your eye forward the login information to the server, and the server validates the information from the security that Hobbes believes note the numbering of messages and how they are changed when they are hitting the object. Thank you for your time and see you in the next video. 14. State and Activity Diagram : Most state machines and the activities show better activation between things happening at the same time, but in slightly different format. Both diagrams, state machine diagram and the activity diagram also show the synchronization between actions and other words, responses that need to be received together to move to the next step. Before we discuss both diagrams, we need to discuss and have an overview over what's called decision tables. When you have many factors that will dictate a decision, will decide on the decision. Is that a yes or no? Create them in a decision table. This will identify all scenarios that will lead to either yes or no status. Best practice to have a decision table for all your status, you can tweak the table to fit whatever scenario you will need. But in the end, don't go directly to drawing, otherwise, things will be quite complicated very fast. So start with the simplest form, with a decision table. I one-factor status question, valid or invalid. Then you can drill deeper to create a special table that govern more complicated decisions or status. So let's take an example of a decision table. For all m, you have two states. It's either on or off. So in both states, you have the valid state and invalid state. So whenever the electricity is on, you have the correct voltage. If you receive the lamp, receive corrective voltage, then it will be valid. But if it received a very low voltage, then it will not be on. It would be something else. Next you have electricity off. So what is the valid for the electricity off? If you have no power or the below the minimum voltage. And the state invalid when it's above the minimum voltage. Because if it's above the minimum voltage, it will be another state which is electricity on. This is a very simple table to depict the different statuses of electricity on and off and valid and invalid for each state in the table you build on advanced to the steam tables for it to determine the possible condition four, is it state as best practice when creating advanced table? Use only yes or no questions, no values. Because the value should be part of the condition itself, from the state itself. Keep it limited to four or five factors. If you need more. Make a new table, since this is a very basic probability, the more columns you have, the more options you will get. So now let's start with a state machine or transition diagram. A state machine diagram is a behavioral diagram that models the behavior of a specific object or a single option based on the output it receives at any given time, this object can change. The status is based on the output it receives at any given time, this object can change your status is or calls Al-Azhar actions to accuse. Let's take lambda for example, using a state machine methodology, we can evaluate all the possible actions that will take place throughout its lifetime, such as on or off, warming, etc. However, there are a lot of possible outputs that can be achieved using this, you have to go back to the decision tables in order to build whatever status is you will need, you have to build it first, as mentioned, to analyze different conditions, much easier. Why do you need a state machine diagram? Not only do state machine diagrams help us software developers, software engineers, on other professionals, to aid them in working more effectively and developing the physical components of a software system. There is also other reasons why state machine diagrams are used, such as it helps do depict event-driven objects in any reactive systems, help to illustrate any use case scenario in a business context, it is effectively describing within its lifetime how an object moves through its various statuses. So what are the pros and cons of a state diagram on the bullet of side. By adding new status is without interfering with existing ones, it makes good maintenance easier for developers. It can be easy to read, modify, and Mundine, especially for larger programs, modularize code into logical status. And on the negative side on the console cannot break code into actual status. It can be time consuming and sense of creating the state machine diagrams as a software matures, the complexity of the diagram increases. So what are the parts of the state diagram? You have the start simple use case for nectar symbol and system boundary, and finally, n symbol. Let's start with the start symbol. The start symbol is represented as a black circle and it signals the beginning of a state machine process and its initial state. However, in a state machine diagram, there is no specification as to who can start the process. It can be anyone. Ones this process begins, it turned into a transition state. You can only have one start and diagram. A Boolean condition is a choice between two things, usually represented by a diamond shape. Use cases or objects. Use cases or objects use cases are represented by an oval square shape with a text in it. It serves as a function of the system connector or transition symbol. And this is usually consisting of a street or curved line with an arrow attached to it. It is part of the transition process where it links with each activity symbol and both the start and end symbol. Writing on the arrow is divided into three elements. You have first, the event, it is the case in which this transition is activated. For example, the case of electricity is on will result in the light bulb as a change a status to arm. So this is usually written next to transition arrow. You have guard condition. The condition only applies for a specific scenario, like the results in the count is more than three. In this case, you present it as account larger than three next to transition text and behaviour, what will happen if the event and the guards are okay? For example, POS, drop what the behavior will be. Next you have the system boundary. And some cases in a state machine diagram, there are system boundaries. This consist of our use cases, activity symbols that are external to the immune system. So in essence, the system boundary is to define external uses. Usually, if you don't have external uses, you don't draw it. And finally, you have n symbol and outline the black circles indicates it. It represents the end of the process. And you can have as many finishes as you wish and the diagram. So let's have an example for a state machine diagram, the state change is an effective change in the status of an object. You can go right away and draw the diagram, but I prefer to listed on a table first, for our online bookshop, for example, we could have couple of statuses. We have Logan shopping card and we have favorite and the possible options for each. For the login, we have the anonymous user and have verified user. We have the shopping cart, we have, it's either empty or full. And the favorite, you have the possible options of empty and full. The state machine is a diagram for only the steep change, not what changing them or how they are linked to each other. If a state impacts on other state, then it can be included as a diagram. For example, the login and the shopping carts are related. Now, start your diagram with the possible options created previously in the table without any specific order. You start with the black circle and end up with the outline black circle and list all the states between two circles. Next, you start adding connections and conditions to turn from one condition to the finish condition. You start by anonymous user openings a website. This user either will decide to login if they are like something, or they might choose to exit the store, there is a choice that will determine the state. Once a user logs in, z will change the state to be unbecoming, a verified user, this verified user now, an axis to two different new status is that shopping cart and the favorites. In both the status is the user can add or remove item, resulting in a state change between the favorites ends, the shopping cart, both can exit changed the items between two status as well. But these nodes that in all stages they user might decide to close the session browser and exit. And this will result in a state change of nth. Though this is a straightforward explanation, you can use it to define a different status is needed and how they will connect to each other. Next, we move to activity diagram. An activity diagram is used to show activities that will occur within a system. It's very close to the flowcharts used to document the flow of the steps that a user will go through. Two defines the possible options. For example, I use R or an actor might be placing an order for a book on Amazon using this diagram methodology, it helps to process the entire step-by-step walk-through that occur between the user or actor and the system process as well. For example, a user or actor might place an order for a book in the shop using Xist diagram methodology, it helps to process the entire step-by-step walk-through that occurs between the actor or a user and the system processes, as well as the possibilities that can occur. For each, uh, process that occurs, it depend on the other. And by doing this, it shows the relationship between the two entities. So why do you need an activity diagram? Activity diagrams are useful as it capture the dynamic behavior of a particular system. This diagram could be also helpful for testers who would need to test the application and make sure it's running smoothly. So what are the pros and cons of activity diagram? You haven't the positive side. It's easy to understand because it's simple layout on non-technical display. It's easy for professionals, professionals to understand what's going on, support and to encourage Barolo behavior makes this good for workflow modelling and multi-threaded programming. You can also do it in swim lanes by using this option. It shows many situations in the workflow in an analytical analysis and you have on the negative side, the diagram itself shows the B6 and not the recommendations. To use the innocence details and facts. It's time-consuming as it takes time to get the diagram in perfect order to display properly. It can only be used for a graphical and theoretical explanation. As the diagram do not show how things combined or how they are. So what are the parts of the activity diagram? The activity diagram has several components that mix it up. But as a rule of thumb, you can use a flowchart symbols to explain the diagram functionality. You have the start simple activity, simple connector, or each symbol, you have merge or decision symbol and you have n symbol. Let's start with a start symbol. That start symbol, as usual, is a black circle and it's beginning of the process and could be a customer or an employee working on the system. For example, the user might login to their account by giving some inputs. This helps start the process. Next you haves activity or action symbol. And action symbol is an oval shape and it included as a function of the system. Every one of these is dependent on each other. The thickest is generally included inside of it as well. Connector or edges symbol. This is a straight line with an arrow symbol, and in some cases it's curved as well. It helps to link each action functions one by one, sometimes called age as well. The one before the action is called an incoming each, and the one going out of the action is called an outgoing age. The writing on top of the arrow will be called guard conditions, the God of the conditions or special cases that will allow the flow if only meets a specific conditions. For example, if n bigger than S3 or similar merging decision symbol, this symbol is a diamond shape and can lead to or from two possible parses, i yes or no question. However, it is a function before this shapes that generates the two parcels. For example, I might be asked to log in to their account. If the user was successful, it moves to the next function. If not, at least another possibility, like trying to look in again or buzzword reset, the decision will have an arrow coming out of it. While it's emerge, will have arrows going into it. That is the only difference. Especial case is one actions that will generate multiple actions without any guarded the condition or decision-making. So in other words, it's one action used to activate multiple actions. For example, two-factor authentication or buzzword retrieval or buzzword reset activity. Lastly, you have the n symbol, then symbol as an outline black circle. It represents the end of the process and everything else before it has to be completed. Let's take an activity diagram example. This diagram is as simplistic view of the login activity and the interaction between the system and they use. Or sometimes you can add multiple user groups by adding different swimlanes. So this walkthrough, the diagram. So you have first, the user opens the website. This is a black dot start condition. Next you have browser books, clicked login, and enter username and password or register if they are unauthorized to access. Once they provide the correct credentials, they can access the storage. Thank you for your time and see you in the next video. 15. Deployment Diagram: The deployment diagram falls in the category of a structural diagram. The deployment diagrams are used to provide display of implementation architecture of the system. It consists of a hardware implementation environment, software implementation environment, and the middlewares that connects both of the environments. They are used to give a visual representation of a software and the physical hardware of a system in comparison with other UML diagrams, they are also assist in modelling the hardware topology. And instead of just outlining the logical component of a system, they are a great help in understanding the physical hardware required for executing the software system. Deployment diagrams act as a medium to convert the architecture from the design phase to the physical system architecture. This conversion will help in a real-time execution of the system and help and structuring how the software would provide policemen across the physical node. So why do you need a deployment diagram? It is used for understanding and assisting in the deployment of a system at deployment diagram, except when the hardware component on which the software component are executed. That's why the deployment diagram and the component diagrams are closely related. The deployment diagram explaining how the component over component diagram are deployed in a hardware. They are also useful at deployment diagrams help the developer to focus on the hardware and software components at the same time. Unlike most of the other UML diagrams that focus only on the software components, deployment diagrams are widely utilized by system engineers to understand and focus on the hardware topology. Necessity for understanding runtime processing that is done by nodes, deployment diagrams, a help and understanding the requirements of our existing system. Too. With recently added system's deployment diagrams play a crucial role in decrementing the deployment of nodes and software components. So what are the politics and the negatives of deployment diagram? On the positive side, it increases the chance of a successful delivery because all the information for the required hardware and software becomes clear and visible. Extremely useful for system deployed on multiple machines. Deployment models are also useful for embedded systems to explain how the software and hardware components work in harmony. On the negative side, it requires some operational knowledge to develop it correctly and developing git add to the coast on time of the software application. So what are the parts of a deployment diagram? There are some specific mutations and elements that you need to understand to draw a deployment diagram. These are nodes, artifacts, devices, and deployment specifications. Let's take node and devices first. So first, a node is a computational asset that helps in the execution of code deployed on it. It is a key element that plays an important role in describing the implementation. Overcoat, and also assist in a medium of communication between different entities present in the system. As shown with the help of a 3D rectangle box with a name written inside the top. Usually we use the word node when code's running on that system. Next we talk about device. I've thickened machines that indirectly assist in executing computation is represented by the node. With device stereotype. It can be a rotor, dummy terminal, or any other physical machine. Now you might be wondering what is the difference between nodes and devise. The difference is actually minimal. But it's up to you to define which is which. For example, you could use the word note for everything and you don't use the word advice at all, or vice versa. You can use the device and you don't use node. You can use the word node four workstations and devices for servers. You can use Node for anything that will run code and devices for dummy terminals. It's up to you to define the profiles that describe both of them. Inside each node and device, you use what's called attributes. Both know that devices should have attributes that explains that box. Specifically. Under attributes your list things like server name, server function, what role does told like example, doesn't have MySQL, doesn't have a database. What are the versions of that specific server? You write its name and instead of the genetic ward server, also, you can include whatever information you think is needed on the attribute that is noticed direction in this one. You can also nest the objects inside each other. For example, you can create a database inside books of a server. Next, we have artifact. An artifact that can be used to represent a wide range of entities. From the framework that you are working on to a source file, database, tables, output files, executable files, et cetera, or any other components. To run them, you use the note. It's a rectangle box with an artifact name written in the middle and the file icon on the right side of the top coordinate. An artifact that can be also a container for another artifact, and they can be dependent on each other. A physical location of an artifact is specified through a filename that contains it. You can show it in multiple ways as an outside rectangle pointing to the code inside the nodes as a line or a rectangle aside. And now we must do deployment as specification. The environment required for running software is represented by a node with deployment the specification is stereotype. For instance, a Java virtual machine is used to execute Java applications and its execution environment. For them, think of it as a prerequisites or the requirements to deploy the software. One or more deployments specifications can be in one device known. And lastly, we have Communication Association. You can use Communication Association to choose a medium of communication between nodes. A single solid line is used that is connected to a node on each side. You can name the protocol like TCP IIB on the communication link. So let's have an example of a deployment diagram. So this is a deployment diagram of a bookstore for nodes which are named web server. I'm middle server, security and data be servers. Customers are expected to connect over the web. Though I omitted this part since no code or running code on the client. But it's also common practice to include it. So you have the webserver. We call it WebServer one type server using TCPIP to connect to the middleware. In our case, we call it M W. And connecting to security server using corporates protocol, which we call it server Z1. And we have HTTP protocol connecting to the database server, which is DBC r1, which is running MySQL. There is another option that is also very common, but it's not your mail standard. But it's also very common when describing and building the servers and deployment diagrams. That's all for deployment diagrams. Thank you for watching and see you in the next video. 16. Component Diagram: During the development of complex systems, it becomes a necessity to break them down into different small subsystems to make the development process more manageable. The component diagram helps him breaking complex systems into smaller subsystems. It is utilized for giving a clear visual over the arrangement of the different components and also helps him presenting the relationships that defines a dependency between different components. That can be software and hardware components present in a system. An example of a software component can be a user interface or a database. While hardware components can be advice, circuit, microchip, et cetera, a business unit can be also a component like a supplier or shopping. Using the other types of diagrams, you understand the clauses and how they interact together. But in fact, the implementation of those clauses is not mentioned in the diagrams. A component diagram introduces the term component. Think of it as a subclass of a superclass. It shows these glosses, interactions through a specific interface of input and output. Like when a web server called the User clause to validate some username and password. This means that each component, for a specific service, something requested and something delivered. A very common usage of a component diagram is to model code entities like DLL libraries. So why do you need a component diagram? The simple answer is to understand the component integrated with the system. Although the component diagram does not explain the functionality, it does give a detailed explanation of the components that make up the functionality. Component diagram shows the working and behavior over different components. Or component diagram plays a key role in structuring a subsystem. We need them to get a visual representation of a physical component like files, memory, libraries, etcetera. I component diagram is also needed in constructing of an executable file. This is runnable as a program file. It's also very useful in distinct a system. It's logical component-based. This means it follows the functions of the applications. Note that T is or the physical location. So what are the pros and cons of component diagrams? On the positive side, the help in development of component-based systems. They are useful in designing systems with integrated hardware. They come in handy for describing the implementation of a system. Or it's the negative side. It is not suitable for designing software like mobile application, for example. It doesn't address what each component does. It doesn't explain how to code each component. It's a technical diagram and not easy for a business user to understand. So what are the parts of the component diagram? The components of the component diagram or you have first the components symbol. You have the required and provided interface. As the last one is the simple. So let's start with the components symbol. There are three shapes to utilize the components symbol. They are the same, but based on which software you are using to draw the diagrams, you will get a slightly different symbol. It's a rectangle with the name of the component written inside it. And you could have it between brackets. You could have it without brackets. You could have it with the file shape on the corner. You could have it who's out, but at the end, it's a rectangle with this anymore of the components. This is the important part. So what are the required I'm provided interfaces. Interfaces are the lines that connect different components and show interactions among them. They are the key players in connecting that require the interface to the provided interface. A hollow semicircle with a line is used for the required interface. And the whole full circle with a line is used to forego provided interface. It is used to represent the components that are giving and receiving services. That requirement interface symbol means needed information to process the request. And usually we have providing and receiving services for a component. And in some cases, in many cases actually, you can have one component. We're providing and requesting services from other components as well. So it's requesting input and output at the same time. Last board report. Ports are utilized to assign interfaces from a component to an internal gloss. In other words, which you gloss inside the component, is responsible for generating the desire. The output port is a small square box released at the end of the line between the rectangle box over component and the line of supplier or provider or requesting information. So think of a board as an entry point to that component. So why draw a board instead of just going through and drawing the interfaces directly? In some cases, you can have a port that actually no other services is requesting anything from it or by providing anything to it. Or the port itself doesn't supply anything to any other service. Security holes. If you have an entry to your system that you actually don't know anything about. So write it down, included if you need such a thing. So what are the relationships in the component diagram? They are the same as a class diagram. I will go through it faster just to refresh the information you already have. The first one is dependencies to components utilizing ball and socket representation can have a plenty of relationship between them. But the most common way of showing a relationship is to use a broken line with an arrowhead is called a dependency arrow. It chooses the dependency of one component on Amazon for its implementation and functionality. First thing comes to mind, what is the difference between the arrow and the ball and socket? The BLM socket is a relation or an extension of another functionality. Both are fully dependent on each other. Data are exchanging between both components and request the supply format. And if it's fails. A complete failure. It is not a partial failure said dependency, however, work in a Fitch gets format. It is somehow one way and the message is relatively standard. So if you have an interaction with a database, most probably it will be ball and socket. But if you have an interaction with a specific different parts of the application, for example, the file server for the images that you'll have, or some of the CSS components if you have a web application. And in this case it might only function as a get request for specific files. So it depends on which kind or you looking and which type of your mail you are trying to address. Ball and socket is mostly preferred right now is a less good versions of UML. But in the earlier versions it was heavily dependent on the arrow. So as long as you include it in their map key, it would be fine. The next relationship you will have an association. It is shown by using a solid line with two ends, depicted by properties that can have the same type and are connected. It is used when there are some relation between components, but has not identified as dependency. So if there is some relationship that you cannot identify exactly what it is, in this case, it is considered what's called association relationship. Next you will have composition. Is this type of string aggregation tilted acquired some part of an instance to be incorporated in one composite at time, a composite is a necessary and if it's deleted, then all parts are also deleted. It is shown with a line with a filled diamond shape at the end. Aggregation it is form of association relationship in which one component can use the functionality of another component, which it makes a type of a sharing property constraint. It is used to show a condition that can be either machine language or natural language to state the elements requirements, Think of it like some sort of a period. Next you'll have generalization. Utilization is a specific classifiers that also inherit the properties of a general classifier. A solid line with the whole arrowhead at one side is used to represent generalisation. This is a parent-child relationship. So let's have an example of a component diagram. The component diagram is used to explain the building blocks of an application and the relationship between each components. And our common example, you have an online shop user interface, which would have its own component diagram. But I'm summarizing this part and the user interface is dependent to function correctly on four modules. Authentication, this is a user access. Books, magazines, and audiobooks. There isn't its dependency relationship in our example is that each module can function independently with the UI. And other words, I will open the UI without authentication and browse the books only. But if they need to make a purchase or add favorites, they will need to access authentication module. Same for books, magazines, and audio books. They are dependent on the product database. Thank you for your time and see you next video. 17. Package Diagram: I'm package diagram in your mail describes the relation between different packages. The baggage is defined as a namespace that is used to group similar elements together. Those elements might even change to get the package diagram belongs to this structural UML diagrams. It's not suitable for small projects. However, they work perfectly for middle and large-scale projects. The dependencies or the relationship between the modules is shown in this diagram. So why do you need a baggages diagram? Minute challenges occur when designing a complex system. Drawing a class diagram for such a system gets complicated and it gets too difficult to understand them and the relationship between different clauses. We need it to structure the elements of a larger or complex system in a form of packages. So complicated class diagrams can be simplified using the package diagrams. Logically related elements or modules are present in the package. We need baggage diagram to assemble larger modules and you use it very commonly a namespace scooping to avoid having the same name across the same elements and causing Nim correlation. So what are the pros and cons of package diagram on the positive side? By using the package diagram, the effectiveness of the design can be easily analyzed. It provides you with an overview of the system. It shows the mean modules without showing the complex functionalities and instances. And finally, it's easy to understand. On the negative side, it does not provide the details of the system. It will be difficult to understand the diagram if it has multilayered the packages with hierarchical bucket, just this mean. Back at juicing, a back edge was in a package within a package and dependencies between them as well. So what are the parts of the package diagram? There are two main components in the package diagram. You have the packages and you have the dependencies. Let's start with packages. The package is a rectangle with a small step like structure at the top right side of it. The name of the package is written inside the rectangle. The baggage is might be dependent on one another. If the elements in one back edge goals change in another bracket, the name of the package can be written in the tab. Though I found the space of writing the package name in the tab will be quite complex unless you are diagramming few packages and you will draw it in a very large-scale. A back edge can be drawn in the form of hierarchical structures. These structures have nested packages in them. You can call it package within a package, as mentioned earlier. You can also mention what clauses are inside this package. Next you have dependencies. The dependencies shape is a dotted arrow, that's it. There are two different types of dependencies and baggage diagrams. You have import and you have access. Let's start with import. The import is used when one back edge has to import the functions over another package. The important is only for public functions. Private functions cannot be important. Next, you have access is used when one package need help from a function of another package. Most of these dependencies are written above that dotted line as shown in the image. The relations are the same as a class diagram. But as a quick reminder, you have first association. It is used when there is some relation between components, but there's not identified as a dependency. Next, you have composition. It is type of string aggregation. A composite is necessary and if it's deleted, then all parts are also treated as shown with a line with filled diamond shape at one end, you have aggregation. It is form of association relation in which one component can be used, the functionality of another component, which makes it a type of a shared the property. You have generalization. A generalization links are used to represent a specific classifier, inherit the properties of a general classifier. A solid line with a hollow arrow head at one side is used for representing generalization links. This is the same relation as parent-child relation. Let's have an example of package diagram. A package diagram is used mainly to simplify the drawing, an understanding of a complex application. This means if an application with simple enough, you don't need to draw it in the online bookstore example, the application is quite simple. It will be nearly identical to the component diagram. You will have the online user interface. The UI can access authentication if the user wishes to access their favorites or make a purchase. You will also have the book module for reading available books, as well as Magazine module to buy and read magazines. And finally, the audiobook module for listening online and audiobook downloads. On the backend, you will have the security of the database that holds the user information and the product database which has all the product information. Their relation R, access to from the online shop you I to the module and import from the database. Thank you for your time and see you in the next video. 18. Object Diagram: An object diagram is a snapshot of that detail the state of a system at point in time. This diagram helps to display objects and their relationships with one another. Object diagrams are an extension of a class diagram. It goes more into depth about a particular system. It's a deep dive into a specific part of a class diagram. As mentioned in the class diagram, a clause is a group of objects. In the object diagram, you draw the objects itself and how the objects interacts to form McCloskey, think of object diagram as a snapshot of a moment of an application running. So instead of mentioning genetic information is a diagram mentions and actual information of an innocence. So why you need an object diagram? It is useful to use as a distinct cases in verifying the accuracy and completeness of any class diagram. It is used to illustrate facts about specific model elements and 0 links. It can even show a particular example of a classifier required. Object diagrams is a great help in contributing to the class diagram. However, the use of object diagrams is limited as they are mainly used to show example of data structure. All of this is a great Hill, denotes the inner workings of a system and how it reacts to certain environments based on its behavior. So what are the pros and cons of object diagram? On the positive side, on the blue side, object diagram helps simplify it down to an incredible levels. It can be used to troubleshoot a particular point of a system. On the negative side, it takes long time to construct. Only one application can be made bear diagram, not as flexible as other diagrams. And some cases, only one relationship between an object and its environment can be done bear diagram. So what are the parts of the object diagram? The format is the same as a class diagram. So please refer back to the class diagram explanation for more details and examples. But as a quick refresher, the components which make up the diagram, our object name, object attributes and links. First, object names, nicknames are composed over several rectangles within the diagram. The claws and the object name is underlined, and there is a column in between the two object names could be an object and the associated actions that are happening with each other. Object attributes. You use object attributes too. Attributes to an object, attributes being an extension over options. It is similar to what can be done. Most colossal attributes are usually listed inside in a separate compartment under the object name. However, object attributes should only show value associated with the object. So this could be a numeric value. For example, temperature, time, that is the height, etcetera for a specific object. Let's move on to relationship in object diagram. These are the same as a class diagram. You have Association. It is used when there is some relation between components, but there's not identified as a dependency. You have composition, this type of string aggregation, and the composite is necessity. If it's deleted, then all parser also deleted. It is shown with a line with a filled diamond shape at one end. Aggregation. It is form of association relationship in which one component can use the functionality of another component, which makes it a type of a sharing property. And finally, you have generalization. Generalization links are used to represent a specific classifier. Is it inherits the properties of a general classifier. This is another word, means the parent-child relationship, a solid line with a hollow arrowhead and one side is used for representing generalization. An example for object diagram. Our example is the online book shopping experience. But in this instance, we will take one class support. Usually you draw the object part directly, but I will deconstruct the clause just to explain it better. You define the values and the expected returns in objects, as well as the relationship between objects. You have your class, which in our case is books, linked with inheritance relationship with the objects. The objects are different kinds of books. And in each book object, there is a relationship between the book and how many customers that book to both favorites and shopping carts. Thank you for your time and see you in next video. 19. Timing Diagram: The timing diagram shows timing constraints on a system. It is a blending of an expected responses to ensure that you have a good timeout plan. If you did not plan this correctly, the system may go into a deadlock mood. And Hank, if you did not consider the time it takes for a specific action, you might exit the application and killed the process very soon, or keep it for way too long. The first one is bad user experience, and the second one will cause server memory and resources that will impact the system performance. Usually, the average response time is seven seconds, up to 20 seconds. But with a huge resources nowadays available for computing power, if you live to a 100 kilobytes, requests for 20 seconds if the memory is not a big deal. So most of the developer leave it at the default. Some transactions, on the other hand, require some thinking. Think of it like a safeguard, the forest, the system or the user. Like time-out inserting buzzword or Ben to accept the purchase. Those still, most developers make it the default and adjust the time of rewards. If your system has a transaction in the thousands or millions, then you need to worry about memory and resource cleaning up. Sometimes this is also called garbage collection. This means that in this diagram can only be used for specific purposes, such as digital electronics like an ATM, digital communications like TCP, IP connections, and hardware debugging. For example, it could be a website. There will be components like we, Bueller web browser, DNS resolver, end that access. Also, these components will have states like ideal waiting, viewing, processing, etcetera. This differ for each one of the components. The time constraints are calculated by attaching it to each state of the component. So why do you need timing diagram? Timing diagrams help limit the timing category to only one diagram, so it is not generally included in other diagrams like the activity diagram. Timing diagram can help to develop the time response of each function, whatever it is, fast, slow, or in between. That is up to the developer. However, it should take into consideration user experience as well. Another good use of a timing diagram is calculating the response time. For example, if you did the sequence diagram, you should notice many steps expected from a single interaction, including a database update. It is helpful planning your responses and checks if it's a specific action happened or not within a specific timeframe. So what are the positives and negatives of timing diagram? All the bullets of side. It can be used to represent the state of an object. At any particular instance of time. They keep track of every change made inside the system. On the negative side, they can be challenging to understand. It is harder to understand than other UML diagrams as it goes back and forth between different states and lifelines. It's challenging to maintain. It. Take long time to develop. So what are the parts of the timing diagram? Several components mix up the diagram. The main ones are lifeline, state or condition, timeline, duration constraints. Let's start with a lifeline. Lifeline represents the name the element in a timing diagram. It is just a straight line represent an object activation during that time. In other words, the lifeline IS a duration, a specific state exist before transforming to another state. This means that the lifeline goes up and down, represents a different states and conditions. The time starts at the left and the progress to the right. Please know that timelines in one diagram follows the same scale. This means the entire diagram has one unit of time, like seconds or milliseconds. Next we move to state or condition. The state is a possibility of something happening at any given time. For any given part of your system, like website, application, server, or database. You can even apply it to clauses and the interactions as well, though I find it way too difficult in this case. So first, determine what component will be involved. Because each part in the technology landscape is dependent on another part. Try to avoid drawing unnecessary items. They use cases, glosses or component diagram to determine the states and the apart that will be included in the timing diagram. Let's take an example. But first, note that the states are very subjective to your point of view. The important part is to get the big ones, the small ones will not make much of a difference. So in timing diagram for a website, it should have web server, it should have idle, displaying content, login, carta update, favorite update. And for the application server, you could have ideal catalog update, refresh that security check, database, update, processing ad request. Now to move to state or condition timeline. Timeline, also called condition timelines are used to show the states or conditions of each lifeline. Now you could have two types of change. You have sudden change, like a kill process, or you can have a gradual change. The process is loading. This is rarely used except for database loading and the container generation. Both will look different in the diagram. You have duration constraints. The duration constraint is used to reference duration interval. It is used to show the process that has been achieved. Usually, it shows how long a particular activity may take. To finish. This is used to display a rough time limit. Not a single digit. Was attainment ruler is a great help regarding the time display for the states or the conditions applied. You could make it exact or relative. For example, you could make a time unit called x and use it as a reference. You will find some transactions you consider it as known or reference and mark it as your x, you start comparing and referencing every other transaction to your first one, the x. So for the transaction, let's call it B. That transaction was Dick twice as much as x. So this will be equal to 2x. So you can have the following duration constraints. You could have unknown or x or n multiplied by x. You could have more or less than, bigger or smaller than, you could have a range of a specific start time and end time. For example, 100 to 400 milliseconds. Typically it shows as an arrow on top of the activation time double filled heads with the duration between brackets. So now let's move on to relationship and timing diagram. And timing diagrams. I mean, relationship is generally seen between the various lifelines and states or conditions associated with each other. Generally, each timing diagram has an y axis and an x axis. The y axis covers the lifeline displayed on the side of it. At the same time, the x axis covers a very sustained or conditions grouped with each lifeline. Also, as well as actions that happen as a results. By focusing on a states that change within a linear time axis, we understand the how time can cause changes in the steepest attached to each Lifeline. So let's have an example. We have our web server and application server. As mentioned, we have multiple states for each ideal displaying content in CT update, favorite update, and for the application server we have ideal catalog update, refresh that, that we secured a check that that was updated and processing requests. We start by listing the activation actors in the left and then the possible statuses. I like to do it in a swim lane for easier understanding. In this example, a user opens a website. So the websites start to display the content and request catalog update from the application servers. Once received, the content is displayed, they use our zen like something and tries to log. Then I knew security session is opened. Once a user clicks login and security verification using the security that amines. And lastly, the user adds a book to the court. Do you notice the webserver behavior is a bit different forums application server. In that case, the web server is maintaining the connection, so it doesn't go down to idle, but the application server fulfills the requirements and goes to the ideal state. You could also add arrows pointing at different activities. And at the time it takes for each duration on the timeline, though, I like it cleanses way to have the time duration underneath in the ruler and without confusing arrows pointing all over the diagram. Thank you for watching and see you in the next video. 20. Interaction overview Diagram: And the interaction overview diagram is a diagram that focuses on the flow of control between the interactions. Because of this, it is widely considered to be a variant of an activity diagram. It is show how set of fragments might be initiated in various scenarios. In other words, it's an activity diagram that is used to document the activities in Othar diagrams, especially in sequence, timing and state diagrams. So why do you need an interaction overview diagram? Because this interaction diagram has each individual activity pictured as a frame, it makes this diagram incredibly useful to software developers and testers. They can be used to deconstruct the complex scenarios that would, in other cases, require multiple passes to be illustrated as a single sequence diagram. As a result, this makes it visually easier to understand when examining it. Also, because of its flexibility, it can be illustrated using one pulse on an interaction overview is used when you have a way to many options or what if scenarios or conditions. In this case, the ruling gets using original diagrams is complex and harder to grasp. So references or other diagrams to build an overview diagram helps everyone understand better. This diagram is considered one of the last ones to be made. So it will usually be dropped and ignored. Or the project did not reach that level of complexity required to have the general overview of it. Or you don't have this many conditions that require you to show this many choices in a system. So let's move to what are the positives and the negative of an interaction overview diagram. On the positive side, it is a complexity of a system, thus making it easier for developers. It is used widely for e-commerce. It shows the different possible over system interactions. The business user can understand it easily all the negative time. It takes much time to develop. What are the parts of an interaction overview diagram. It has several components that makes up the diagram. You have the start symbol, control float symbol, use K symbol, decision node, and n symbol. Let's start with the start symbol. A black circle represents the start symbol and it signals the start of the process. It is usually the user starts this process. Control flow. The control-flow serve as the bind that connects the elements, which includes Use Cases, decision nodes, and start and the end symbol. It is represented as a straight line with an arrow attached at the end of it. Interactions use cases or interactions are represented as a square shape with text included in it as well. Its surplus primarily as a function of the system process. Each use case lead from one to the next. So this bind them together. This process continues until the very end. Where's the system process is now completed? You will have mini sequence diagrams and timing and state diagrams. You don't have to redraw it. You just mentioned the reference name as a pointer to a specific diagram. This way, the reader will not be overwhelmed with way too many details in one diagram. But anyone interested might look at that reference diagram to understand more. Next, you have the decision node. The decision node is a diamond shape. On the diagram. It shows the different possible parcels. And finally, you have the n symbol. Then symbol is represented as an outline black circle. It marks the end of a system process. So let's have an interaction overview diagram example. Let's take our previous sequence diagram. Though. This diagram is already simple enough. I will use it as an explanation only. You take the original sequence diagram, you create a sub-sequence diagram out of it. You split it into interactions. For that sequence diagram, you can extract three main parts. Let's call them reference one, reference to and reference three. Now we start drawing the actual interaction overview diagram, referencing each part of the SQL diagram in its interaction shape. It helps to add one line to each shape describing what it is to avoid going back and forth between diagram, it will look at the end at very high level, very simple to show the different poses that you can go and your sequence diagram. That's all for this video. See you in the next one. 21. Composite Structure Diagram: A composite structure is a diagram used to show that glosses internal structure and the associated interactions with this gloss. Although it's closely related to a class diagram, a composite structure diagram allows you to view the internal structures, the details, and interactions. This diagram is not very popular and this frequently used. So why do you need a composer to structural diagram? A composite structure diagram is a great help in allowing users to peek inside the cloth to see its composition. Also, by showing exists the internal actions of a class can be detail much more. This also includes the relationship of nested glosses. This diagram, great details is used why hire skilled developers and the engineers to troubleshoot a system with a non errors. What are the rules and call off the composite structure diagram. On the blue side, it's very useful for studying the inner working of a particular component within a system. It can provide developers with information to optimize and troubleshoot their systems. It helps to detailed runtime architecture and usage patterns. On the negative side, it can take long time to construct. To understand it, you must know a particular component. Only one diagram bear workflow. So what are the parts of the composite structure diagram? The main components are, you have ports, ports, and other words, objects and connected. Let's start with port and interface. A port acts as an interaction point between a classifier's behavior and its internal parts. It is represented as a small square. This is the interaction between the class and other classes that don't have the required provided relationship. This port can be used in dependencies. For example, usually it's a small square at the beginning or the end of a diagram. The interface is the same idea. Choose a deeper interaction levels, and it's represented by a circle and the circle shapes. Next we have part. The part is a diagram element that belongs to the structural cloth. It is usually represented one or more instances it thrown is described each time. These parts are what makes up the cloth. These are the objects inside the cloth. The common attributes between these objects is called property. They are common in all of the instances, but the data it contains is different. Like the server name with each object that data will change. Let's have an example. Start with an object. This is considered an instance of an object. Two terms this object into a part, blank out all information and data specific to that object. You are left out with the blank information. In our example, you'll have author, name, ID, type without any specific information. Now you have your glasses and the parts in it. You break out this parts into separate boxes. Each bar has a number which contain how many instances of this part is allowed within this cloth. For example, you could have one or more authors, but you have only one ID. You could have from one to four covers from back, spine and the author photo, for example. Next you have property. These are the property used by this clause. They are outside of the class and might be used outside of the class as well. These are things like attachments to this objects. For example, a sample chapter for the book. It's not inside the class, so you only attach it to the clause. Also, you have singular and instances. This is something always fixed within the application, like company logo, copyright disclaimer, company contact information you listed as well below property. And finally, you will have connected this elements served the bind that connects all other elements. It is represented by a line in the diagram. Each line will have rules, either reoccurring or matching rules, and how much of this connection is needed. The function is complicated. You can also break it down to what's called collaborations. This is how objects themselves will cooperate to deliver the needed functions, like product listing, for example. And the product listing. You have to get the information from the database and displayed. Both actions are configured to only a response to an object off shore products. But in collaborations, you separate them into multiple actions. It is very detailed and rarely used. So let's have an example by merging all of the components together. This is the full diagram you will get. You will have book, author and ID and cover, attach a file and copyright. In this diagram, you mentioned how things interact together. That a book can have one or many authors, but a book can have only one item. The book can have for cover photos from back, spine and overall size, or an author photo. Chapter artifact will be attached from outside of the clause and a copyright claim. That's all for the composite structure diagram. And see you in the next video. 22. Profile Diagram: A profile diagram provides a generic extension mechanism for domains with a specific applications and technology. These diagrams are usually defined using stereotypes. Take the values, definitions, and constraints, which applies to modal elements, including glosses, attributes, operations, and activities. Now the profile diagram is not for the software, it is meant for the UML model itself and other awards. It submitted data itself. Let's have an example. You have a beer at gloss that has a, B, and C attributes. Child day of class has an attribute of a, d, e. This means that inner child a, the following attributes are available, B, C, D, E. Because private attributes is not inherited. If we need to expand this understanding to match our requirement, we need to create a new object type called grandchild, and that you could actually type called restricted inheritance. You do that by expanding the model itself because it doesn't exist in the original UML. Now with our example, two things happened. You create it at your arrow type. This arrow with a lock on it means conditional inheritance. Only attributes with protected will be inherited. You have a new object called grandchild. This extension of understanding at what the various models can't do is the profile diagram. Why do you need a profile diagram? So diagram is used for a wide range of system applications. This is especially useful for software developer and software engineers who would require a diagram to expand and to understand the extensions to them eat a model. Let me rephrase that because programming languages are popping up with different models almost every year, you will need to expand your authentic language to make it adjustable to whatever you are trying to do with whatever tools you will have before this gets confusing to you. These things usually happened, ends up drawing software under and Michelle properties. It is adjustment to expand. What the software can do. It is merely adding a new template to the software so that you can just drag and drop around or adjust to an existing object by attic up particular value to it. You are limited to one software can't do. In other words, you are expanding the customization of the software. This diagram value to list all Customizations, allowing the reader to trace back what these objects are and from where these values are originated. For example, if you read and install the software, you will lose all Customizations. This diagram will guide you all the customization of the your male model. Another example is trying to change an old software. Stan, what extensions happened during that time? What are the bruise OK, call the of the profile diagram. Although bro side, it's really beneficial for software developer and software engineer's. It helps to simplify any complicated system to make it easier to understand because you are creating your relationship to simplify the complications or the negative side, it takes long time to develop to many customization will make the original order neglect useless. So what are the parts of the profile diagram? This diagram is heavily dependent on which software you are using. The parse will change as well. But the main components which makes up the diagram are stereotypes, tag, values, and constraints. Let's start with stereotypes. Use stereotypes to increase the vocabulary of the doorbell by using this element, you can add and create your model elements by adding your building blocks. Do you automate? It, makes it look more closer to your situation, representing the stereotype to whatever you wish to expand. The model represents the stereotype with whatever you wish to expand the ordered with. Write it down between brackets. In this example, I'm expanding the model to include next generation firewall to the model. This could be anything and your bottom function or device or anything you might need. Next, you have tagged values. Tech devalues are generally used auto elements at used or add additional information. Uml has a limited number of tags that can be used, but it allows it to expand and create tags using predictive values. They are agreed use in expanding the properties of this UML diagram, it can be used to specify a keyword value bearers of the model where keywords are the attributes. Let's assume you want to include that. You think that your company called a digital ID and you want to have it in all objects. In this case, this tag is unique to you and needs to be included. Finally, we have constraints. Trees are regarded as the function property which is specified semantics or conditions. This must be true all the time, as it's the only way this element works. By adding you could strains, you are extended to the semantics of the your mail building blocks. In other words, not all things that can be created without additional requirement. For example, the minimum order value for all isotropic should be $10. Or to qualify for free shipping, you need to spend $100. Another example, the firewall default rule must be deny access, otherwise is useless. You adequately strain of the firewalls that has a default rule of denying access. So let's have a profile diagram example, XO, it's called diagram. It is just the customization. You'll make it our diagram just to establish relationship with different elements. You will list all of the elements you create it in a structured way to make it a bit more organized. In my example, I expected the UML with three stereotypes that next generation firewall at L3 switch, at L2 switch, as you might want to read right now, why you will ever bother with this diagram? Actually, you don't most BPAs, doctor, with z just generate a key. It is the same as the rectangle of the bottom-left corner of maps that have the elements and their explanations. Business analysts use this key diagram they make. Mitch and every rule they adjusted profile diagrams is only used if you've made significant changes that you need to rewrite the your mail to understand what's going on, which is very Lisa case. Thank you for watching and see you on the next video. 23. Entity-Relationship Diagram: This is our base design is a domain of its own. But since this will significantly impact the performance and the reports, you need to understand the how to design a database. This way, you can at least have an absolute foundation to develop an application that will perform as expected. Usually, most databases use the application. Our relation a b is the unstructured data is covered by entirely different concepts and it's not covered in this course. Also, as I, database management systems or DBMS like SQL, MySQL is not covered as well. Instead, I will empower you to have the generic knowledge and underlying understanding you need to make a design decisions. Some application comes with recreated that the business schema. These are usually off-the-shelf applications. You don't need to design that a b is, in this case, all you need is to create an interface or just the formulas by expanding the framework. And maybe create one or two additional tables to hold the capture that information. So let's have a database overview. Let's start from the beginning. What is data? Data is a product over business operation. This definition means you can use data around three main pillars, decision-making, course correction, regulatory reasons to reach dimension three goals. You need three things around data. Keep it organized to maintain it for long periods. Security to ensure that no one would see something they should not generate useful information out of it that are keeping evolution. That start with book records. The first data keeping mechanisms are accounting and customer books used in the old days. You keep the customer contact information in one or two books and keep it in a safe. And whenever you need something, you scroll to the first letter of their names and update their last visit or contact them. This will, if you have up to 1000 customers, maybe a few thousands or even. But what if you have more than 1000 customers? In this case, you have to move to a spreadsheet. Now we need to structure data a bit by making all of this information into a spreadsheet. The spreadsheet will give some additional benefits of searching through data, retrieve the data faster and deter mine any missing information. But even spreadsheets have their limits. That challenge will be generating meaningful information like who lost the visited us, buy from us, or updates or visit record. If you try to do it manually, it will consume lots of time. Is a column in excel sheet is called a field. Usually each field container specific value, and each row contains a group of fields, usually for one customer. For example, field is the name, address, and phone number. Suppose you are trying to expand this to what they like and dislike and additional information like lost to visit date. What allergies the half, you will start to run into data sorting and filtering issue the same as the beeper book. It would require some manual comparison to get the correct data. Now, here comes the relation that obese, you create everything using a table and break down the fields as much as possible to the core data. Think of diabetes as a collection of spreadsheets, but you build relation between them and optimize data as well. For example, you have a customer information at one table and what they like, and another table. The menu and assert the table and what they are ordered last time in a force table, separation of data across tables will allow you to build relation between tables to determine what this customer might like in your listing and will enable you to provide recommendations. Now what if you have lots of customers building set of tables for that customer is complicated and hard to maintain. Law. It can't be taught. I saw it a couple of systems. The customer did not wish to restructure the old system. The downside to this method, when you try to modify something is quite complicated and takes lot of time. And the report of the building is a time-consuming. The tables and relations, how many tables and what information in this table to hold is called the schema. Trying to optimize this further, we have to create what's called a key. This is leads to creating the key field and all tables to refer to a specific customer. Now we have some Id that can be used across all tables and link tables together. Instead of having tables for one customer, you group some fields, are lick them using the key field. Key-values or unique values are values that cannot be duplicated in the same table. Like firstName, lastName might be shared across customers. So either you will find something unique about the customer, like for example, generate the username or generators field to ensure that you can identify each customer by a specific numeric value. Based on the database management solution, you can make a key out of anything. Still, I found it useful to add a field dedicated for that. This kind of key is called a synthetic key. It's named like that because it's not part of the original data and use it as a reference across multiple tables to build the relationship between tables. More on that later. Now let's have an overview about database design. The first step in database design is to plan what attributes you will need to store incidence obese as a starting point, you use a class or object diagram to determine what's needed. What if you discover some attributes you need to add to the database to make it more optimized. In this case, you need to modify the application to include specific attributes. Otherwise, it will always be blank or it will not be populated with data. Database design is also a prototype to determine what's required. And in most cases, the database design, she gets a new light on the requirements nor addressed before. This is why designing the database has critical part of the application creation process. Otherwise, you will have to deal with issues coming from the application side because you did not do the initiative that is designed correctly. Another word of caution, do not translate clauses in the table. You can, but it's not recommended. Usually use cloth diagram just as your starting point. So let's have our previously created class diagram. You have a few things in our example. Each of them will be requesting specific attributes, incident diabetes. In our example, the entities are the books and the customers. The customers, you need to maintain the following attributes. Firstname, lastName, address, email is administrator, user ID. This is a synthetic key. Note that the user three clauses are joined together. Next, you have the books. You need to maintain the following attributes. Book name, author name, type, publishing date is a best-seller book id. It's a sense that it gives Well, since this leave us with two special tables required, favorites and guard, since a customer could have 0 or many and each, it would be wasting that the business space if you just keep adding fields, columns next to the customer name was favorites or card. Since as mentioned, one customer could have 200 favorite guard and another could have 0. To solve this problem, create a new table with Many-to-Many relation. The many-to-many relationship links the customer table keys and book table key in one table has rows. Note sometimes this is referred to as a bridge table as well. From this table, you can understand that that customer with ID five have books 101214 and his favorites. And customers to have also book ID and their favorites as well. Now the same concept applies to core table. Usually for this table, you will create a key to identify each row as well as synthetic key. So what are the key type we discussed key, but what are the general key types you have forming key types. First, as a primary key, a key directly exist in the data, like the order number, for example, it's part of the data and it's unique. The key is also identify an entity uniquely and must be three things. Unique, never changed, and never blank. Or you can have also a synthetic key used when no part of the data can be used as a primary key. So generate one and inserted into the table must be unique, never changed, and never blank as well. Usually you don't, you'd read that a key unless you don't have a primary key, but avoid wasting that a business space and processing power generating these keys. The third key type is a foreign key used when a key is used in another table lot the table it's originated from, they don't need to be unique and host table. And finally, you have a composite key. Create a key from two different attributes, like to foreign key used to create a key in a table. For example, shipping table has an order ID and a customer ID. Both are foreign keys, but both will create a unique composite key. The key cannot be changed. This is why we never use for numbers as keys. Unexpected changes to fix it. Things are also why lots of DBAs, database administrators, but a ferrous insert a key because it's independent from business operation. For example, the business operation might decide to change your format of the order ID, which will cause the problem in the database. Now, let's move to database optimization. The word that obese optimization combos address the DBMS systems and that is a structure. And example of DBMS optimization is adjusting the memory, building indexes, and this is usually the daily operations of the database administrator. Nowadays, all database management systems. Ron, from the memory and this level, the playing field in thermal speed. But still, if you do have a large database or planning to have one, it's a good practice to try to optimize the data to improve the engine functionality and performance. It's good practice when building your database to ensure it will not require an extension, adding columns or tables to the database or that B3 design and migration. So what about a giant? Should the database follows as a practice that is OB is usually adopt that. But the initial design must be done at the beginning of the project based on the original use cases. So the database itself does not need to get built from the start. At least, you need to understand the basics of the application. Use cases as a data captured when creating your database. So designed that the bees in envisioning fields and actually create a table and the relation is adapt phase. This is why it's called a structured database. Structured data in tables, rows and columns, and building relationship between them. The other side of a structured data is the unstructured data. Unstructured data, you store the data without knowing what relationship between the items is. Think of it as a larger block of text. And then you depend on some level of artificial intelligence to analyze and extract meaningful information and meaning data out of this, you could serve as a business analyst usually will be so that the business structure for the previously mentioned reasons. You should know some basic rules of database optimization doctors that how to build the fundamental database. This design knowledge will allow you to discover water requirements, and this is the purpose of this entire practice. The general practice of the optimization are to reduce data publications is the practice of eliminating that obligation between the rows and columns and prevent repeating data. In our example mentioned, you have one rule that has duplicated information, ID 34 are the same and the fields, type and books results at the same information as well. But instead of rows, it's a column based. So you can optimize this by removing further application in data. You can remove the row or the column based on which you think is best fit for your situation. Next, proceed to table optimization rules. This is called normalization and had three main rules. The first normal form is easily spotted, ensures that each cell has only one piece of information, not a list like our customer, like EB and see if you have the comas or a separation between items. This mean piece of information to explain the customer desires or walls, usually more fields by adding numbers to the field, like book one, book two, book three. This is a huge till that you are violating the first normal form. If you need a list, you need to create a table and liquid a specialty will, as mentioned previously, you could continue with normalization form second, third, and beyond. But this is the domain of its own and you don't need it as IBA. I'm just listing them for the information purposes. The second normal form is any data you can extract from. The data, like one field is continuously showing up with the other field. The third normal form, no data can be extracted. From another field based on the general rule, like for example, price and the price of discount. And if you are offering discount all items. So this can add a field called the price after the discount. In this case, you know how much it will be because your discount is fixed across all items. But if you are offered a discount only some items, then it's okay. You can leave it as is, because then the rule is not to general rule. So let's have some practical salts or optimization. It's all come down to the expected data size. If you have small database, it will not matter because the power of the DBMS engine at the loadings at our database, that memory will make these changes minimal. But if you are planning to have a relatively large database, then you need to consider this seriously. Now the questions that will come to why and what is large and water small, usually, the server memory divided by two equal the largest possible that a B, if you cut the rod without caring about almost anything. Really, this is a case that database is terabytes rages right now. And your server will be around 512 gigabyte of memory. And even if you got appliance for the database which counted terabytes and memory, you would still run out of memory before you run out of storage. So that, that this optimization is almost as long as you're expecting data come again. Now, let's draw the ERD for our database, the entity relationship diagram. This diagram is used to demonstrate the data schema in the database and how it will connect. This helps you to understand the interaction between theta and optimize a database storage and use the performance early on. Why do you need an ERD? As mentioned previously inserted, that is one of the significant contributors to the performance of the application. If you miss the sign it, the reformers will drop significantly. Also, changing the database is quite tricky after the actual application implementation going live or go into production. You can extend that easily, but rearrange the data is not easy. So it's better to understand the customer data requirements and plan for it. So let's understand parts of the ERD. First, you have the entity. These are the things that your model that you need to keep the data around. In our example, it's the books and users or customers. Unless you have the attributes. These are the pieces of information you wish to keep about these entities. They have several types. You need to know this because it will help you design the fields columns in your database. So accurate analysis of what's required is critical. You can have a simple attributes. This is a single value, like an ID number or a serial number. It cannot be separated into multi value or multi-part. You cannot separate it into smaller values and you will have a composite value. This is multi value, have a several components like the address, for example, apartment number, three, number, and which city the customer resides. You can have also this and either stored or drive the story. You get the input directly from the user. The user have to import this specific information. You have to import, for example, his phone number. And you can have it as derived, you generated based on other information you've got. For example, if the user inserted the address, you can take the city out of this address. You can easily get the city out of it. So what are the shapes of the ERD? There are two primary school at diagramming that database and building that ERD. You have chains database notations, and you have your melt database notations. The first one focuses on understanding the differences between shapes. Diagramming a very detailed database designed. It was quite good. But for database admins, the other one is a UML, which is quite simplistic. You have the entity in your mail and chance are the same. You have the attributes. It's a rectangle, but it changed. Bhopal item. Multi-valued attributes is not existing in the UML, but have popup attributes as well. You have derived attributes. It doesn't exist in the UML, but exist in the chain. You have the primary key which exist in both your mail and you have something called weak entity, which has no value can be used as key, doesn't exist in your mailbox, existed Chen. And finally, relationship, which is a lie in your metal, but it changes. It looked like a diamond shape. Next we move to what's called relationships or the cardinality. You can link tables using many types of relationship. You have one-to-one relationship. This is what row if data connected to one row of data and another table. This is us doing Separating parts of the data across tables or databases like the username, buzzword relation. You can not have them both in one table. You must separate the tables to apply some additional security to Rose. Usually, this is drawn as this and this is used, you have one-to-many, many-to-one dependent. How would you look at it? Customer ID relates to multiple things. They like their favorite books, for example. So they can be linked to multiple things or multiple things that can be linked to them. And you have finally, many-to-many. It is used to create a special tables like favorites or complex scenarios where the user have multiple existence in a row. These are the basic relationship or the basic cardinalities. There are many more used across different classes and different scenarios must lets take a straightforward example to demonstrate the connections. In our example, one customer can have many orders. So what does this connection means from left to right? In this case, it will be what? It means that the Customer ID is just one and can exist many times. And the order table, and from right to left. In this case it will be many to one. It means that all orders with the same Customer ID can be traced to one customer. And you probably noticed the linking between tables is done through keith. This is why keys are really important for you to understand. You might also notice that this will generate too many records in the order table because each customer can order two books bear order number. And either the customer will have to reorder to get more books or the system will generate multiple orders of the back ground, you will have to create another delivery table to batch all these order together. And as mentioned, this is not the recommended way, but it's used to demonstrate. Instead, use what's called a bridge table. This will allow each customer to jewelry and order ID, but shipping address and each order ID could include as many items as a customer wishes. I know this might sound complicated. In reality, this is very simplistic application. The whole objective or drawings that ERD is to understand the restrictions that will happen because of how data is stored. This will require you to capture the information you'd never thought that application would require as burgess date and time, for example, you will require the application to generate it. So this will be part of the application requirements you should list for the application to generate at when the customer does this by operation, you should also make the application generated on their back ground. I believe that, that at least with it, you need to generate many things like order number given to the customer, but you are generating many requests on the back end, each requests mapped to one specific book item that will be part of this order as much at the earlier. You don't have to draw with a technical complicated diagram, but you need to think about this because this will save you way too many issues down the road. Thank you for your time and see you in the next video. 24. Deployment Consideration: The term change a bit between creating the code and deploying it. You need to know how to deploy the previous parts because they impact the operation significantly. You could create one application on one server that deliver the same function as an application on the servers. The difference would show when you try to scale your operation. So you should always worry about not only the interface code and as obese, you should consider the application architecture and where the code is running and where the data is stored. Lose this is should have minimal impact on the user requirements. It is considered that good to know. Don't understand how things will fit to deliver the value needed by the end-user. What should you be concerned about the operation loot? The primary reason for that is that it impacts the application performance as well as the application maintainability. It is a balanced either to make it super easy for the development team and make it quite challenging to operate and maintain, or vice versa. The more you build it as a separate components running on the cloud, the more time you will invest in creating the application. But on the other hand, that time will be recovered in the operation when you try to update or even fix something. So it's a balance you have to maintain. The modern practice are to develop every application as a micro service, or at least makes the application as a service oriented architecture or so on. And the deployment will cover containers and maybe even over cloud. This quick overview of these topics, let's start with cloud computing. The National Institute of Standards and Technology defines a cloud as a set of characteristics. Its on-demand, self-service, network access, resource pooling, rapid elasticity, pay as you go with three livery models, you have SAS, software as a service, platform as a service, and infrastructure as a service. The new trend, this now X as a service where x can be anything. Disaster recovery as a service, IT operations as a service, business process as a service, et cetera. The cloud could have three deployment models. First, private cloud, you own the hardware and as for the organization use only, you have public cloud from a cloud provider with pay as you go blink, you don't own the hardware and sometimes the software as well. And finally, hybrid cloud, I mix between private and public. Next you move to cloud delivery models. You have three cloud delivery models. So this is getting more complex by the day. And subcategories show up almost every day between the primary models. Always consider IAAS Infrastructure as a Service, as an entry level. Only, develop your application to run as Software as a Service or platform as a service, it will be cheaper and it will have fewer operation issues. So what are the infrastructure as a service? Assert the party provide hardware, software, storage, and network. You are charged by either pay as you go based on your consumption or you have a fixed amount, a contract, bluffs Bay as you go if you go beyond the contract. Next you have software as a service. Sas assert the port city entity provide hardware, software, storage, network, and software provisioning, software maintenance and update. The end-user provide the operational data only. You only provide the data. And finally, you have Platform as a Service or passes. A certain part of the entity, provide hardware, software, storage, network, software maintenance and updates. You provision your software on top of that platform and configured, for example, containers, summer weather, if you consider databases as a platform, as a service. So it's dependent on which provider you will choose. Next, let's move to application architecture. Where did the microservices come from and what problems are solved? Dr. stanzas, you need to know is the high levels of the history of application development. First, we used to have what's called the monolithic application. That monolithic application is a single application package that does several functions and deployed all at once. This is considered a single tier application. It is self-contained and exhibit that from other applications. It provides a complete function, not one single toss. This means larger scale releases to batch or add features to the software. After that, we got service-oriented architecture. In SOA. Each application component is independent and utilize communication protocol to communicate each part, provide specific service to other parts with a specific outcome. Each part is self contained. The downside of it is that either okay or an error. Nothing in-between these status is a typical software in SOA is presentation layer, a business process, logic, and data access. The problem in solar is a connections. If it's too complicated, it would be easier to create using a monolithic application. And finally, we have microservices. Microservices idea is to create the code or the system or the modular level. All communications is over API and any unit can be called from any other unit is a system. Microservices is not a cloud. It could be on the cloud, but it's not exclusively on the cloud. Microservices is doped the size of the service, but the operation of the service. Each part is a small, be tested with for use scenarios and can be deployed. Foster. This allow you to build the services, not for the maximum possible load, but the average load and allow for scalability whenever required. Elastic availability. Microservices is entirely open source concept, which means it's cheap or even free. Some cloud providers also supports it. The issue with microservices is a number of artifacts you will have to maintain. The more artifacts you will have, the more complex the service would be. The two issues with microservices are network latency. Increase the network latency due to the increased number of cold from one system to another. And you will have the distribution code. It microservices, this cost will be higher than more complex setup you will have if you have two milliseconds latency per single goal, imagine what will happen if you got 15 calls. The latency will grow and might be a problem. Also, avoid cycler calls like service one equals two and then to core one until either one of them timeout. This will significantly increase the latency of the coal. So what are the microservices best-practices? First, you need a circuit breaker. In all systems, use circuit breaker after several connection attempt, the system is assumed offline. This will allow other components to work around this part, not by mouth. This is what's also known as bimodal clock. If you build a system without this functionality, a single component failure might call the cascading failure that bring down the entire service. Next you have setup, grouping, and syllabus breakdown. You have to build surface data flow diagrams to understand how the system is talking to other systems. If it's discovered that there is only two systems talk to each other, then I would suggest merging them into a single data domain. Use your best judgment when deciding on surface boundaries. And finally, the API layer. And this is just an aggregation proxy for your services. It should not have any logic and its main purpose is to shield the services from being called directly by endpoints and instead into points called the API layer. And the API layer distributes the calls to the correct system. Think of it as a router and the network traffic. Now, we move on to containers. Containers are the way of deploying application. Containers are not virtualization nor do it replace virtualization. It's modular approach to deploying at transporting applications. It works best with other technologies as well. Like for example, microservices containers are growing year over year. It's expected to reach 100% of the application delivery is the next seven to ten years. So why containers? Containers provide agility, scalability, high availability, coastal optimization, and portability. So what are the common use cases? Continuous integration and continuous development and automation, auto-scaling, microservices architecture, of course, Containers as a Service and hybrid cloud architecture. So what are the advantages of containers? Docker's, for example, as one flavor mixed Linux containers, easy and reliable, better resource utilization, same or S, multiple processes. And instead of having multiple VMs or multiple operating system, you can actually host everything on one or S. Lower application conflicts. Run, catalog, application or multiple operating systems without getting mismatched version. Better application compatibility can copy the containers between environments, between production and reproduction. Easier release management because it will be small and very portable. So what are the differences between container? And the virtualization, it is not a VM, it's a collection of data and application back together to have liquidity and the agility container are server-based application deployment. Almost all technology is based on scripting files. The VM is better because it's increased security since each application has its own OS. And the virtualization technology is a standardized by now, the negative or the downside of the VM is much additional overhead because of the S. As a foundation, if you run the operating system view each running container, you have to revise the design. If you have a standard like BCI, for example, options in container applications like Docker's can't do isolation, but it's best to separate them on different systems. Containers are not simplifying the development lifecycle. And instead, it increases the complexity of the development because you are adding layers, creating the containers to the mix, but it makes it the operation, maintenance, and support much easier. Currently, loss of application vendors to ensure the application is functioning properly, create their own containers and handed over to the customer to run it on the OS CME as a virtual appliance concept, but with containers. So let's design a container. You don't store data inside the container, you never do that. The container is short-lived. Typically use container for microservices or the front to end the middleware of your application, the business logic. But always you keep your data in the database is at one monolithic database or small multiple databases. You can launch as many as you can from a single container. This will allow you to process several requests in parallel. You will require some orchestration tool to automate deployment and container creation. This will simplify as a final service delivery. And rolling back and rolling forward, you can move the same container between distinctive staging, reproduction and production environment. So this tool, the most common one, is called copper neatness or K8, but it is an open source orchestration system for Docker containers. It handles a scheduling nodes and a compute cluster and actively manage workloads to ensure that their state matches the user declared intentions. It is responsible for creating clusters and scaling up or down containers instances running of the system. For example, document goal. When it launched, it had a huge surge before stabilizing. What if your business is seasonal? In this case, scaling up and down will help you meet the required demand without actually wasting resources. Cooperatives that has many flavor based on it. Each has its own vision thread to get one. To simplify the control process, I really see someone deploy Cooper neatness with its vanilla original format. Usually you will get some flavor based on it. Now we move on to network communication. Usually this part falls outside of the UML diagrams and software development as a whole. But unfortunately, you need to plan for it or at least understand the language that will be required from you to deploy the application between different components, you need to consider three things, or at least ensure they are key with the network and security teams, you will have first the bandwidth requirement, security requirements like protocol ports and encryption. Finally, authentication. The starting point is that deployment diagram. You get the deployment diagram and start doing bandwidth requirement, the network bandwidth, let's do some terminology. Is the maximum bit rate per second measured in bits like 100 megabyte, 100 megabits, or one giga, giga. You will need to divide this by eight to get the bite. This will results at 1G gigabit connection can transfer only 128 megabytes per second. This is very slow for a server virtualization. This will reach a maximum of 80% of the physical network. The remaining 20% will be consumed in translation and network layer. And secondly, latency is that our trip duration of the bucket from the source to the destination and back to elements are critical to calculating the application network bandwidth and the timeout duration. The timeout duration we already discussed in the timing diagram. And for the network bandwidth, you will find out how many calls you should send their connection. It's a formula. You have the expected user account, the expected number of requests. You have the average size, but requests you have the expected number of connections. So let's assume you have 25 user expected. Each user opens the upside and browse five books on average. The average request size is calculated based on the sequences. Of course you regenerate. So to simplify, let's assume each call is average of 200 kilobits, except the last coal, it's three megabytes. So you will have five multiplied by 200 plus one multiply by 3 thousand divided by six. Because you will have six goals from the sequence diagram to this equal 670 kilo bit bare. Cool. So you will get the sequence diagram and start counting each one of the steps, each one of the jumps, each one of the goals. Now let's calculate how many jumps this goal will go through the network part, the deployment diagram it shows as for connections. So you use the sequence diagram to calculate how many calls you will have and use the deployment diagram to calculate how many jumps you will have. This means that each average user, 670 kilobytes jumping for connections equal 2700 kilobytes, which is roughly 2.7 megabytes per user. Now the total number of user is 25 multiplied by 2.7 will equal 67 megabytes required. This calculation is the beer second calculation. 25 users per second is a big number for a small shop, this means they should get around 90 thousand customers. Bear our Usually it's more like 0.0002 or less. Now let's move on to security requirements. Now for the security components, you will have protocol. You have to define the protocol we will use. Some protocols are disallowed in the network and the intrusion prevention system might block some goals. So you will need to ensure that both the system calls and the protocols are allowed by the security team, board or supports used on the server allowed, you should have both source and destination port to ensure the firewall will not block the connection. Encryption. Though it might seem a good idea to encrypt everything from the application itself. But actually, the security team will help you in generating the security keys at might require some connections to be unencrypted to detect any attack happening on the system. And finally, we have authentication with your application hold all the security information inside it. For example, on a specific table, on the databases, or you will use a specific authentication repository for that to allow other surfaces to use it as well. For example, to have a single sign on or to have more security constraints on the specific system. Consult your security team on how to do that and what's required and what's the company policy of holdings formation. That's all for this video. Thank you for watching.