Hello friends. I'm Sanjay Gupta. I welcome you on Sanjay Gupta Tech School. This is my website, studysalesforce.com. So here you can find all video links related to Salesforce. So you can watch them. And in this video, I'm going to demonstrate you the implementation of before insert, before update and before delete together on a particular object. So I will be implementing it through a fixed river. So let's first understand the scenario. So for before insert, I will be updating the account description. So whenever a new account is created, so we will be updating the description of the account, right, then when account report will be updated. So when we are inserting any accounts, so this description will be there as soon as you update the account and its phone field is updated. So then you need to update the description again, having a text like phone is updated. Right. So let's say, in case of insertion, we can say account record is created and in case of updation, we can say our phone is updated. And third is before delete. So here you can see a requirement is mentioned like show error when an active account is deleted. So on account I have one pick list that is active. It is having two values no and yes. So if it is having yes then we need to show the error like you cannot delete the account otherwise account can be deleted. So now moving to the org. So here you can see I have created account trigger on account and three events I'm using before insert before update and before delete. So here I am going to check one if condition if trigger dot is before and inside this I'm going to check. trigger dot is insert. These are trigger context variable that I'm going to use else if trigger dot is update and else if trigger dot is delete. Right. So these are three blocks now and here I can call the respective method that I want to execute. So I already created account trigger handler. So one by one I will be explaining the methods. So this is the first method that is for update rating or so in my scenario I told you like we will be updating the description. So here we will add that as well. So update rating and description. Right. So I'm little bit modifying the scenario. So this method we need to call so in insert we can use the name of class account. And dot name of the method then trigger dot new. So trigger dot new contains all the new records those are inserted. So this list we are passing and that list will be received by this new list. Then we are iterating this new list with the help of this loop and we are checking if account dot industry is not null and industry is equals to media so we are setting rating as hot and we can also do one thing. ACC dot description equals to account is created. So this message will be available in the description. So let me cut it from here because we want this description to be populated every time whenever a record is created. Whether industry is null or not null or it is media or not. So this if condition will set the rating as hot. Otherwise, rating will be none and description will be populated as account is created. So I'm saving this So I'm going to create new record. So I will be creating two records. So let's say test ACC one here I'm sorry I'm not putting rating. I'm just putting industry. So if industry is not null and it is media then rating will be hot automatically. So here you can see rating is blank right now and description is also blank. So I'm clicking on save one error is available at line number four method. Okay. So I updated this method so I just I'm just pasting it here and trigger dot new I'm saving this as well. Now I am again clicking on save. So here you can see record is created if we move to the details rating is hot automatically and if we go down. So here you can see description is having account is created right now. Let me create one more account. So this time industry will be blank. So still you will see still you will see description will be populated. So I'm not putting any industry. So you can see industry is none. Clicking on save. So again you can see one more account is created if we go to details so rating is blank because industry was blank. So that if condition won't work. So at the bottom you can see description is still populated as account is created. So this way I hope you understood how we can use this before insert. So in case of before insert you don't want to apply any dml because this trigger dot new that we are using or we are having a new list is editable. So whatever you want to perform some modification here you can do so that will automatically done by the trigger. Right. So this is before insert now moving to before update. So I'm copying this method here. Account trigger handler dot method name. So whenever you are going to update any record. So there are new records or new state of record will be available as well as old state will be available. So trigger dot old map. So new list is passing the new state or new values of the record and old map will be passing the old values. So this we will be having in this method. So new list is having new state and old map is having old values then new list we are iterating if old map is not null. It means we are updating because old map is having something it means record is updated. Then we are checking the phone. So ACC dot phone. It means new phone value and it is comparing with existing value. So old map dot get. So we are getting the value through get method. Then we are passing key as ACC dot ID. So value will be this complete account information. So from that we just want to fetch phone. So if new phone that is available through ACC dot phone and old phone that is available through this if both are different. It means phone is modified. So we are updating the description and we can also put older new values as well. So let's say is phone number is modified and equals to and I am using the ACC dot phone. So this will be the new value that I am going to concatenate. So as you know we created two accounts and both description are having account is created. Now I will be updating the phone and you will see description will be updated with this phone is modified on account and this phone number will be available. So I am saving this. So only phone field whenever phone field is modified then only this description will be modified. Otherwise not. So I am moving to the account. So this account we created right now. Test account too. So I am going to update the phone. So right now it is blank. I am putting 1, 2, 3, 4, 5. Clicking on save. Moving to the description so here you can see phone is modified on account and phone value is also available. Then again if I modify this. So let's say 54321 and if I click on save. So again you will see the modified value is available here and if I move to test account one. Right. And if I open the details and let's say I am modifying the facts. Right. I am modifying facts value and at the bottom you can see description is account is created. I am clicking on save. So this time description won't be updated because we are not modifying the phone value. So this way you understood why this condition is important because if phone is updated then only you want to update the description so that you need to check this condition here. So that's why old map is required and new list is having the new states. So this way again you saw we modified this new list only and this new list is having values from trigger dot new. So again this is before update or you can say before trigger. So here trigger dot new is in form of editable mode. So you can update that as well directly. Now third scenario is whenever we try to delete any account and if account active field is having value. Yes. So we need to show an error message. So let me first all this method here. So account trigger handler dot then this method. So in case of deletion we don't have any new state of the account. So we have only old state. So I'm passing trigger dot old. So this you need to remember. So trigger dot old will be received through this oldest that is list of account. I'm iterating it then checking each deleted accounts active field value if it is yes then this error will be added. So add error is a method that will update a particular record with this error message. So this will be this error will be displayed whenever you are going to delete the account where active field is having value as yes. So here if we see active is blank. So first time putting active as yes clicking on save. Now I'm going to delete this account. So you will see an error message. So are you sure you want to delete this account. So I'm clicking on delete. So here you can see sorry you cannot delete accounts which are an active state. Right. So this is test account one. Now I'm moving to test account two. And if I move to details. So here you can see it is having active as false. So now if I try to delete this record. So it will be deleted. No error will be thrown because active field is having nothing. So this way I hope you understood again. We didn't apply at any DML. We just modified the oldest and oldest is having trigger dot old. So this is also in form of editable mode. So in case of before trigger if you are using trigger dot new context variable or trigger dot old context variable. So you can modify their values and you don't need to write any insert or update DML statements. So they will be modified automatically. But if you are moving to after trigger then you need to perform DML operations because in that case trigger dot new and trigger dot old are in form of read only. So this I also discussed in the introduction video of related to trigger. So this way I hope you understood all the three scenarios that I demonstrated for before insert before update and before delete right so more videos you can watch on study salesforce dot com. So here I put all the links related to videos those I created for Salesforce so you can watch them as well. So I hope you understood all three scenarios well. Thank you for watching this video.


Well, it was a little bit of March madness in February for some area basketball players. Josh Peterson was there as special Olympic basketball teams hit the courts. Bemidji State University's Rec Center was filled with the competitive spirit as special Olympic basketball teams from the northwest region of Minnesota competed in a basketball tournament made up of six teams that were ready to compete. Our basketball teams are composed of our traditional athlete and what we call a unified partner and our unified partners is somebody who does not have an intellectual disability. Each team is made up of three Olympic athletes and two unified partners. The unified partners come from all backgrounds providing a successful chemistry for each team. The unified partners come from corporations that are locally based. They come from various other venues maybe at a college level that come in just to kind of be a pal. For Darren Hansen and his teammate Scott Hurst playing basketball together has inspired Scott to take on a leadership role looking up to his friend and teammate Darren as a role model. But Darren has been a big influence in my life for being a good role model so I've learned a lot from him. For the unified partners just being there and becoming an active coach both on and off the basketball court can leave a lasting impact. Well I think having the partners be active with the athletes is I can't even express how important that is. It opens an eye to the community and everybody else and just you know makes everyone part one team. Anyone that has a curiosity about Special Olympics and its programming are encouraged to check out all of the other events and programs they offer. Anybody that's interested in Special Olympics come and take a peek if you don't know what we're all about and look online and see the areas and what events that we have going on come check them out. In Bemidji, Josh Peterson, Lakeland News. Each team had the opportunity to play two games. The area tournament qualifies the athletes to compete on the state level. If you've enjoyed this segment of Lakeland News please consider making a tax-deductible contribution to Lakeland Public Television.


I have a freelance gig. Don't send it my way. I'm too busy. So busy that I haven't even made the slides. What I have made is this tutorial, this workshop. I've turned it into instructions. So you can visit this GitHub URL and browse the code with instructions with me using the tags. So you should check out the tag 0 first. So today, we'll try to build a RSS reader. So this will be our end result. Yep, this will be. So it is called yet another RSS reader, YAR. So we'll have this simple entry to read the post, to fetch the post, add new post, and filter by the feed, filter by if we have read it or not. And we'll not use any frameworks. What we will use is RxJS library. Anybody familiar with FRP or RxJS? Anyone? Something with the adapter. Is it readable now? OK. So this is what we are going to build using RxJS. So first of all, we'll get into what RxJS is, what FRP is. First, are you guys going to follow with me or just going to watch? Is it visible now? So I guess you guys are just going to watch. So we'll do a show. So is there nobody following? Really? The URL? This it is. Yeah, github.com slash that. Yeah, that's a Punjabi name, so bear with me. All right, so we'll use ES6. It is awesome, that's why. And we use Webpack to compile everything to ES5. And RxJS, we'll come to that. So if you are following, better just clone this repo. Check out to this tag too. Check out just press 0 and tab. And it will take you to the tag. So I'm already there. So first thing you would do is install the npm dependencies. npm i, it will install stuff from package.json. So what do we have in package.json? These are the dev dependencies for, it is readable? Not at all. Want is good, actually. Adapter is bad. Is it? Well, cool that. So in dev dependencies, we have this Babel core, Babel loader, and all that, the Webpack stuff. Drop it. And in dependencies, we have Babel runtime. We need it for, say, some ES6 features. And it is good to have because it helps optimizing the transpilation. And we have our app divided over several files. And we have this HTML to H script. We'll use virtual DOM. So at the point, we get the HTML feed. So we have to convert that HTML strings to virtual DOM. That is what it is for. And we'll have offline storage because an RSS reader without offline storage is not an RSS reader. I just said that. We are going to build an RSS reader. And we'll not use any framework. We'll use RxJS library. And is this what you were asking? We'll get to Rx. Forget Rx for now. You know virtual DOM? We'll get to all of them. Just listen why these things are here for now. So Dexy is a library over abstraction over indexed dv. We'll use that for offline storage. And there will be jQuery. We will not really use it, but it will be there. And Rx, of course, and virtual DOM. All right then. So let us drop the webpack stuff. This is the webpack config if you would be interested. But let us assume that everything is working like magic. And so what we are going to do is we are going to, we'll write our source code in the source folder. And everything in the source folder will be compiled to one file in the disk folder. And it will be called app.js. So that's what we include in our indexed HTML file. That's it. Next, we just start with the coding. So for testing, we just have a console.hello world. And I'll start the webpack server. No, you can't. If you want to use that, you can't. Then you'll have to run webpack in watch mode so that it will keep watching the changes that we are making. And webpack will provide us this library load. Got any? So and webpack actually don't write. Webpack dev server will not write files to file system. So the library load is very fast. Let's not get into it. So our code is running. Webpack is all set up. Let us start with what is next. The second tag for the first step. So what is RX? RX stands for reactive extensions. So heard of reactive programming? Anyone? OK. So reactive programming is like when we say we have data in our apps, right? So when data changes, we have to monitor it and watch for changes and do the appropriate changes elsewhere in the data or in the UI. So reactive programming is what we shall call that we change the data and the UI should react to it. Or anything that is using the data should react to it. That is what react does, right? React, we have state to change the state, the UI plates. That is what Angular scope does, Angular 1 scope. And Angular 2 does the same thing using observables. So that is what we are going to use here directly. So we know what a promise is, right? So promise is a value which don't have its data at one point of time. When we create a promise, we don't really have the data. We create a promise and then promise resolves sometime in future. Promise resolves once. We get one value. The observable is like an array of promises, a collection of asynchronous data. It will resolve more than once. And it is like a push-based collection. So we have a value in anybody attended the Bottle keynote yesterday? That was on RX, right? She built a game, I think. I wasn't here. So we have value in our usual programming. We create a variable. And its asynchronous version is the promise. And we have an array in our usual programming, a collection of values. And that is what an observable is in asynchronous world. It is a collection of asynchronous values. So we start the Webpack server. And we start the Webpack server. And first thing we do is import that observable. We are using ES6 modules here. Anybody not familiar with them? It is like doing this, like we create a variable and require RX.observable. This is doing the same thing. Now, what is an observable, actually? So observable is like a promise, but a slightly different API. We, to get a value from observable, we have to subscribe to it. So let us take this example. First, we have an array of numbers. And we convert that array to an observable using observable.from. It will convert most of these imperative forms to an observable. And observables, the good thing about observables is that they provide a functional API. Like for our arrays, we can do map, filter, and reduce. We can do same with observables and even more. There are a lot more operators. So like we want events from our numbers collection, our numbers observable, we do a filter operation on it.  What this does is it basically creates an anonymous function, like we would in usual JavaScript. And if we miss the braces around, it will just return the result of this statement. So we get the events. And then we subscribe to it. When we subscribe to it, we pass it a callback. And this callback will be getting the actual values from the observable, like here. So we get the even numbers from our collection. And we can convert promises to observables. We have this array of URLs. And we convert the array to an observable first. And next, we use flat map. So flat map is like a map. Say we map over an array. And the map gives us an array of arrays. So we flatten it. At end, we get a single array, a flattened array. This is what flat map does for observables. Like now, this Ajax request will give us a promise. But we want the value. So what flat map will do is that it will create the promise. And what it will give the subscribe method is the response that we'll get. So we aren't really logging it. Here it is. It is asynchronous. So although we are, sorry, it is actually, you can say, even driven programming on steroids or observer pattern on steroids. So the advantage of this is that it provides a very functional API. Like we have the filter map reduced on arrays, array extras. So we can do the same way for asynchronous programming. We can have multiple asynchronous stuff things. And we can compose them together. Like we have an array of URLs. We can make a request to each URL and get the response in correct order. And pass them through this map and filter and all that to get what we need. So now this is all asynchronous. This is not blocking anywhere. So we have other code running. And the response gets in the end. The response is logged in the end. So in the same way, there are many operators on observables. Like we have this interval operator. The interval takes time in milliseconds. And give us a number every this many seconds. And we can compose asynchronous calls together. This is asynchronous, right? It is like having a set interval. And we have another same thing, like set interval. And now we want to merge them together. So what this will do is say, we are now having this merged thing. So it gives 0, 1 first, like on every second. Because we have a 1,000 callback, 1,000 interval. And then we have another which emits every two seconds. So we are having the other one is running along with it. And we get it at proper time interval. We'll stop it. And we can convert events to observables. So like we have click events or resize events on window. We can convert them to observables. What benefit it gives is that, say, you have a click event. You add a click event to, say, the body. And then you have an event listener. And then you forget that event listener. What we get is a memory leak. Now, what observables does is make us think the events in terms of data stores. Like our event is actually an array which will give us a value whenever user, that event is profound, whenever user clicks, or whenever the window is resized, or whatever. And we can compose them together as well. For example, we have this combined latest operator. It takes two observables. And it will say two observables of clicks, clicks and resize. Now, these observables will get value when user clicks or resize the window. What combined latest does is that when user clicks and then resize, it takes both values and give them to our callback that we provided and then returns what we provide. Complicated? I was told that I have to build on bottle stock. I was expecting some familiarity with the FRP. Never mind. So we have this set now. Now, when I click it, actually, it will not work this way. So whenever I resize the window or I click, I get the notification that this observable has done something, has got something. What it has got is what I returned here. So we are not really doing anything with that. We are just logging it here. And then there is this zip operator. It takes two observables. And whenever each of them, say, responds, it combines them and give us to this callback and return the whatever we return from this callback. So here we have even plus odd. We had two arrays. We combined their values, 0 plus 1, 3 plus 2, 4 plus 5, and likewise. So I don't think you guys are convinced about observables, their power and all. Observables are actually very cool concept. I wanted to convert you guys from promises to observables. It seems hard. Anyway, we'll proceed. I don't want to delay the magic moments. Then on to our next step, to the virtual DOM. So have we used React? How many are familiar with the React? We are all jQuery people. So React is a really awesome framework. It uses virtual DOM. So DOM manipulations are expensive. That is what is said when we start using jQuery that don't do too many of them, combine them together and do them as few as you can. So this virtual DOM is a library which keeps a representation of DOM in memory, not the actual DOM in memory representation. And whenever we want to change something in the DOM, we create the whole view again. Like we create a new DOM. And then this virtual DOM will perform the, say, dipping. It will see what changes it needs to make. And it will change the actual DOM. Only the most optimal changes it will perform. So let us see how we can use it. First, we use our observables as always. And we have to use this edge from virtual DOM. Edge is for hyperscript. So hyperscript is like one level up the virtual DOM. Virtual DOM will interact with the JavaScript objects directly. Hyper level is one level next. And then this is create element. It converts the hyperscript to what virtual DOM actually understands. And then we have dipping and patching algorithms, the functions which will actually dip and patch the changes so that we can only get the optimal updates. And we can actually use this HTML-like syntax in our code because we are using Webpack. And I have added a virtual DOM loader. So what this will do, this will get converted to hyperscript automatically. We don't have to do it. But we have to convert the hyperscript to virtual nodes later. So we have a render function. It takes a count. And it returns us an H1 tag. So then we create a view. So from our, say, call this our hyperscript, from our hyperscript, we created our DOM. You can call it a view or you can call it a DOM tree. So after this, we have to then convert our view to virtual nodes. So the virtual DOM has one condition that all the virtual nodes must be contained in one parent. That is what we call root node. We create root node. This is the root node. In our case, it is only one. We only have H1. And then we append it to our body. What this will do is just this. It will just take this. We started with zero. The count is zero. And it rendered the hello world. Next, what we want to do is that we want to make it like this. So what actually is happening is that only this H1 is updating. Actually, only the one text node is updating. We have the text nodes in the tags. So what we are doing is that we are doing the same observable dot interval thing. What observable dot interval will give us? One people I told you. It will give us a number every 1,000 milliseconds. It will start with zero, then one, then two, then three. Then we map over it. In the map, we keep getting that number which the above observable is returning. For the every time we get a number, we recreate this H1, the whole view. And when it is recreated, we dip it with the previous view that we have, the new view. This map returned us a new view. And we used it in our subscribe method. So we create the dip. Then we patch the dip. Like this root node that we created earlier, we patch it with the dip that we got. And then we replace a previous view with the new view. That's it. We don't tell it how to update. We just tell it what to do. We just tell it that when you get a number, just generate this view. And it will update it pretty optimally. It will update this on text node only. So we are not clear with the virtual DOM either. Yeah, this is the code. I am not getting you what you mean or what you want to see in the network there. Of course, we have in our index.html this slash app.js. So all our JavaScript is getting compiled to ES5 and minified and put it in this app.js file that we include in our index.html.  So for doing library load, it don't put the code on file system. It will keep it in memory so that library load is very fast. We can compile it to, say, with Webpack minus p production. We can create our production or disk code. And it is taking time. Then we can see it. This is how it looks like. It is compiled, minified, and totally unreadable. OK, so let us start our Webpack dev server again off top of the HTML. So this is what we are doing here. We write this, say, JSX-ish syntax in our JavaScript. So in our Webpack config, we have loaded a virtual DOM loader. So this tag will actually get compiled to virtual DOM later, a thing called hyperscript, this edge thing. We gave it as an input. And then we appended it to our body. Then we just update it, and virtual DOM manages itself that how the already rendered DOM shall be updated. Yeah, that's the new trend. We can separate it. So it is just a function. So we can put it in another file and import it, like we are importing other functions. So you resolve promises. What's the guarantee that the promise that you resolved number three will not get resolved before number one? Then they are all resolving at once. And how will you compose them? So you have one set interval. This is a very simple use case. You don't even need promises for that. So the advantage of observable is this map. Now I want to do something else with it. I don't have to mess all my code. It is very composable. So you can just look at it and see there's one map operation. It is doing x. There is second map operation, or something else. We will put it up, because here it is getting. The advantage of observable is first this, say, writing code in a stream-like way. We have these functional operators. We can do whatever we want with the observable, with our value, until it reaches this subscribe. When it reaches subscribe, it all ends. This is where the observable ends. We can change the operation. Second is the, say, predictability. Now this is a very simple use case. Imagine you have an array of, say, 100 URLs, and you create a promise for each one. Now what you have the guarantee that which one will resolve first? You can use the libraries like Q. But after that, it is not really that composable. The composability, this is the composability part. We can compose small operations to generate, say, to manipulate our values in the way we want. We'll see what it can do later, just in a minute. Now that we don't have this clear either, we'll move forward and to the third step. Now you don't really know React. So React has put this very nice idea of programming in terms of components. So all our UI, we compose our widgets like separate components. They are isolated from each other. They don't need to know about each other. And it makes the reusability very, say, intuitive or natural. So we want to create a similar system, but without using React, actually. We want to have a components-like system. And we don't want to use React. And we have virtual DOM, right? So we want to render stuff. We are on third step. React actually has a slightly different implementation of virtual DOM. React first introduced virtual DOM. And then people say that, oh, it is cool. I will make one too. So this is another implementation of this same concept. So then we want to create a renderer. Like in React app, what we see is that things like this. Like we include the root component, the layout. And we just call a render function. And it will render it and our app begins. Whatever changes we make, they are optimally updated and all. We want to achieve the same thing without using React. How do we go about it? So first of all, we were appending to a body. Remember, we were doing document.body.pand. We'll create a span, give it an ID, and append to that span instead. Is it readable? So we create that base node where we will dump all our virtual DOM, and we do it. And then we want to make components. Let us just divide our code into components. We had these two things, hello world, a greeting, and this counter. So we created this components folder and created these two components first, the counter and the greeting. So basically, these two have nothing special. We just divided our, put h1 in one of our elements in one of our components, and we return the render method. The same thing that we had earlier combined. We split it into two files, and we are basically having the same code in both of them. Now this export default thing. This is in ESX, we have to tell what we want to export. Like in Node.js, we do no module.exports. The same thing. What export default does is that it will, if someone do like this, import directly the variable name from our module, then it will, by default, give this render function to it. So then we'll, now that we have two render functions here, we have two views, the two components. We want to render these two components onto our screen. What we do is that we change our index.js to and we import them, like greeting and counter. Now these are two functions which will give us h1 and a counter. Don't worry about it, man. We are using Webpack and we are using Babel. It will transpile your ES6 code to ES5. Just clone this reference, right now. It isn't working, see me after that, after the workshop. It will work, it is, I am using IOJS, but most of the ES6 features are not really implemented in IOJS either. You can run it on Node 9 even, I think, 0.9. We are using Babel. It will take the ES6 code and make it ES5 code. So we imported two of our components and now our render function will look something like this. We have our count. We convert the count to a string. And then, remember I told you virtual DOM needs one root container. It has to have a parent on the top. So we create the parent and then we just put our components in there. So we have components, right, right to it. And then rest of the code is same. We just, we do the same thing. We map it to render method and then patch it, patch the DOM that we have rendered. And this code, this rendering code, actually don't belong in the index.js file, right? Because index.js is responsible only for updating the view, not creating the view. So we'll create it to a root component, call it main.js. So it will import all the subcomponents that it needs and give us a single render function that we need, that we will use in our index.js. So clean code. And the next thing is that this state, this observable.interval creates a count, right? The count is used in the counter component. It don't have anything to do with anything above that. It don't have anything to do with the greeting component or the main component. So we shall put the state where it belongs. So we can do that. We will just take this observable.interval and put it in the counter.js. But then we don't really have the value. What we will have is an observable, right? So counter.js will then return a function which will return an observable with me. So this is a thing I have chosen to use. So any observable is represented by underscore at the end, because it is a stream. And any function which returns an observable shall do the same, just something I came up with. You don't need to use it. So now our render will give us an observable. So we need to update our main, because earlier it was relying on a function which gives it a virtual DOM. Now it is getting an observable. So we update it. What we do is that we take the counter, the counter observable, and map it with this main view, the big view. So what this counter will give us is only the count view, the text node, the one text node. And what we want to do is put that one text node in our div, the container. That's what we do. So the composability for the win. And we can then change our index.js file to look something like this, because now it is consuming an observable. So if we want to use it elsewhere, it has to return an observable. So that it does, it returns a render observable. And in our main.js, what we do is that we import the main as main view, and then we subscribe to that view, instead of creating an observable interval. So this is what we get at the end. Actually, what it will give us in the end is something like this. So it will not render for one second. It will start rendering after one second. And start the count at one. That is because we have done this n plus one thing. So why is it acting like this? So this interval, what it does is that it will wait for one second and then give us a value. And we are using it directly. So this is what it is happening. It is waiting for the value. And when the value comes, it is rendering. But we want to render immediately. We don't want to wait for the observable to give its result. So we start with a default value. We start with 0.  So we have an idea how our components are going to be. The components which need to update will return an observable. And the components which don't need any operation, they just are there to see the show will return the DOM nodes. But that is not good, right? Consistent systems are maintainable systems, right? Because if some component is returning an observable and some is returning a function, another one is turning a DOM node, not very good. So what we do, we change all our components to return only observables.  It will create an observable which will finish after returning this one. So why are we doing this? First is consistency. We want a system to be consistent. And second is composability. So after we have all these greeting and counter both as observables, we use combined-lay test. Because we don't want this greeting to be ran every time, right? Because its job is just to return one H1 tag. We don't want to run it every time. So what we do is use this combined-lay test. What it does is that once this greeting has emitted a value, it will cache it. It will cache it until it emits again, which it will never. So we use this cached value. And this counter updates every one second. What we get in the end is the index.htm.js file like this. So we create a render function which takes the main view and the DOM node to which it has to render everything, the base DOM node that we have. And then I just restructured the code to contain all the operations in one function. So this is basically a closure. We can move this to its own file and call it renderer. What renderer will do, it will provide us this render function, and which will take one view, an observable, and the DOM node to which that observable is to be rendered. That's it. So we moved it to its own file. And we then end up with this simpler index.js. We get our main view observable, which is the whole view we need. And we get the render function from the renderer. And we just render the view to the DOM node. And it is updating itself optimally so. It is only updating this span, which it should. Everything else stays static. It has the same interface. That is what we were aiming for. We want components like React, because they are very nice. Isolate components are the most reusable and most scalable. So we want that interface. And I like the React interface a lot. Just have a render method, give it the main view, give it the DOM node that you want to render. And that is what we get here. And without using React, it is not really JSX, but it is like JSX. Oh, no, we can. I just chose this because ES6 just makes the code so much more readable. Now this same code would be written something like this. So we can reduce it to basically one line. So now that we are not clear with this either, we'll move forward. So the events. Now we have a virtual DOM. The DOM is in memory. Before when a script is loaded, nothing is rendered. So how do we listen for events on something which is not even there? Like I want to listen for clicks on a button. I want to listen for clicks on this button. But before, it is actually rendered. Because when a app starts, when a script loads, there is nothing in here. So what we can do, one thing is that we wait for it to rendering. So maybe our only option. Or the other thing is what React does. What React does is that it will have, say, on click equals the function name, the event listeners in that way. So remember, we used to have this in the pre-Jquery days, or maybe in jquery days. We just have a DOM node. So we have this button node. And we want to listen for an event. So we will do it on click equals listener. But that is an approach React has chosen. And I don't really like it for, say, tests. But we are using observables. And observables are good at composability. We can change the operations and get what we want at the end. The difference between promises and observables. So what if we put an event on the whole body? We put a click event on the body. And then we keep filtering it until we filter the target to see if it is this click button. Performance optimization. So you have 100 buttons. If you put 100 listeners on 100 buttons, you have 100 listeners. And now with this, you have one listener. And you are just filtering it. Then you have one click event. The whole body is one line away. It is actually, this approach is called delegated events. It has its pros and it has its cons. jquery use it for your information. If you look at the jquery dot on the function, it actually in a way uses delegated events. So in this console, what I have done is that whenever we click on body, so it logs the event. I clicked on whatever, it logs an event. So what we do is that we check for the target of that event. Where is the target? And now target has class names, this class name. Or it also have a property called class list. So what we do is when we click on it, we create a function that will give us clicks by class. So it takes a class name. When a click happens, we get the event. And then we convert it's a class list to target.classlist. This one, it is native JavaScript. It will most likely not work on the older browser. But we are not spotting the older browser. We should not spot the older browser. So when I click on it on anything, it creates an EV on window. So this is our mouse event. So EV has this property on its target called class list. So I clicked on here, it don't have any classes. When I click on the button, it has a class list. This is not really an array, because when we do operations on DOM, it has its own hierarchy of array. It is not really an array. So we convert it to an array with the simple utility function that we have created, a two array. Of course we can. And what will we do with that? So now we have two buttons. And clicking on this button does nothing. Clicking on this button updates the counter. Why? Because we have different classes on them. So different ways to get the events. One is this. We put in a single event on the body. And then when an event arrives, we check its target. And we filter the target if it is what we need. We can have similar way, clicks by ID or whatever we want, clicks by the DOM node even. And what we do is that we return a new observable. That observable is the clicks on the element that we have. So in case of count click, what we have is we create a new observable, count button clicks. And then we work on the observable. Now we are getting the event, but we don't want the event. What we want is that we want to update this DOM node. We want the view to update it. So for the view to be updated, we need this count. So what we do is we create, start with the count equals 0. And when the click happens on this button, we increment that count. At any point in the chain, we can use this do operator to check what we are doing. The do operator is like, say, you tapped inside it. It will not do anything. It will just do some side effect. I'll start with the observable. I had to get the same value. That was turned by the observable before do. When we click it, we say we are incrementing our count. And we start with 0 so that we don't have to wait for the count, because if we wait for the count, nothing will be rendered, because now it is waiting that someone will click that button, but there is no button. So we start with the 0. It gets up there. And we convert our number that we are getting to a string. And then we return this whole view, this complete view. So then the magic of that renderer comes in. We don't need to go through all the hoops again, because it is all reactive. We just update one observable in the whole chain. And the chain will rerun. So if we look at it, nothing else in the DOM will change when we click. Only this count is changing. That is all thanks to virtual DOM. This is how we are going to have our eventing system. So for two buttons, say second button. For second button, we have a different class. Now we want to listen for the clicks on this class. So we do the same thing. Let second button clicks equals the function that we created, which will return us an observable of clicks, clicks by class, and then the class name. But by itself, it will not do anything. To get a value out of it, we need to subscribe to it. So this button does nothing, just log them event. So yeah, we created another observable for that. That is what we want, right? We want to handle the two buttons separately. We don't want to mess them together. So that is about it for our event system. Event system is very simple, nothing complicated, no need to add event listeners, then remove event listeners. We just have one mother of event listeners. And that's about it. So this approach actually has some side effects, some bad thing. For example, let's say homework. So our next step is to fix the feeds and some styling. We want to end up with a view like this. The internet is slow. I didn't talk about the error handling system. Now we have this whole chain, right? Each view returns an observable. Then when we combine those observables, and it becomes a big whole chain. So what happens if an error occurs anywhere on the chain? We want to handle the error. So we have two ways to handle the error. We can handle the error right where it occurs, or we can have a handler at the end of the chain, where we subscribe to it. So where we subscribe to it, we have this error handler. This is the next handler, which will get the next value, and this is the error handler, which will get the error. So what it does is just log the error. So we have an error here. What it says is that this utils.format date is not a function, because it is expecting a function somewhere in our utils module. And it says it is not there because it is there. Let us see where it is in the post view. That is not waste time on it. OK, now CSS is messed up because of this resolution. Oh, no, it is a zoom. So now we want a view like this. We have a sidebar, and we have a list of our RSS feeds, the post. For getting the post, we have to first fetch them. We have to make network requests. So for that, we create a file called feeds.js, and we will export an observable saying feeds from it. And we will use the feeds in a component called post list. This list, say import these feeds, and then operate on it. It takes the posts, which comes with each feed, because each RSS feed will have 10 to 15 posts, an area of posts. Then it creates views for each post, and then it combines all the posts because if we have three RSS feeds, there will be three arrays of posts. So it has to merge them together. For that, we have reduced. Have we used reduced before? Reduced before? It's an array extra. So we have an array. We want to find a sum of array. Basically, we want to reduce the collection to a single value. That is what reduced does. It takes an accumulator and a new array that we have, and it just combine them, concatenate them, and give us the result. And we pass it to our view. The view we don't need to worry about right now. It's just markup. And then we have this view. But how do we request for those feeds? Say we start with this one. This is taking an array. It is taking that huge DOM that view we create. Say we have this post. This is an array now. This is an array of posts that we will get from the feed. Now we convert the array to an array of views. We map over the array that we got, and we converted them to views with the post view function. Now we have the big array of views. So that is what we pass to our view function. This view function, the post view array. It will render it accordingly. No, no, no. Reduce will do this. Reduce, first we have this post. Post is an array. This post, the first thing, is an array of posts. That we start with. Now the second time this array comes, it goes to reduce. And reduce expects two parameters. First is the accumulator. Second is the value. Now the accumulator, when we don't pass it, it will assume this post as the accumulator. So this is our post is our accumulator, and we get new posts. And then what we do is, accumulator.concat, new posts. Then the third time it is the reduce run, it will have its first element as the combined array. And it will take new posts and combine them as well. We clear with this? This one? It is like we got an array. Then we get another array, two arrays, because we have three feeds there. Now we got two arrays, and we combine them and make one array. Then we get third array. We combine them with the previous big array and return the big array at the end. So for fetching the feeds, we start with an array of URL. So here's an array of the RSS feeds that we want to fetch when we have nothing in the front start. And we create a helper function to fetch the feed. We import Ajax from jQuery. So it is just like doing where Ajax equals the required jQuery.ajax. So what we do is that we change the URL that we have, the RSS feed URL, to this thing, the Ajax.googleAPS.com. This is because if we try to request this feed directly from our JavaScript code, guess what will happen? It's a cross-site request. It will not go through. So few RSS feeds set the proper cross-region header, good for them, the nice people. But few ones like this unison don't. So the request will not go through. For that, we have to use something on the server. So that something on the server will fetch the feed for us and give us the result with proper cross-region header set. That is what this Google API does. It takes the URL of the RSS feed, parses the URL for us, and provides us a JSON feed. And we make the request, and we return a promise from it. So this fetch feed function will take a URL, make the request, and give us a promise. We want to use this promise for making the three requests that we want to do. So what we do is that we first convert this feed URL's array to an observable, because that is how we compose. Observables are composable with observable or promises or generators, only these three things. So we convert the array to observable, and then we flat-map it. Remember the flat-map? So what we do, this fetch feed will take the URL one by one, and it will create a promise and give us the promise. At this point, we have a promise. Now promise will resolve at some time. The promise dot then is called. So what this flat-map do is that it will take the promise and keep this thread on hold till the promise resolves. And the next step will actually get the response whenever it arrives. So when I say it holds it, it doesn't mean it blocks it. It just holds the one request. Say it made the first request, it is waiting for it. It then makes the second request, waits for it, then makes the third request. And as the results come back to us, we'll keep getting them in this map ahead. We get the response, and the response will look something like this. The response objects will look like this. It has a property called response data, which has a property called feed, which actually has the real feed, the feed URL, the link, the title, and the entries. These are the blog posts that we are interested in, that we want to show here. So we do that. We take the response and provide the end result, the post that we want. So then we create a post list view. What this post list view does is, like I showed you, it expects arrays of posts, like we subscribe to feeds, and we get an array of posts here, and we do the processing and render the view. And all we have to do is then at the end is return this render function. And we change the main.js. First import this post list view. It is an observable. And then we have this view setup, just the container stuff, which has this post view that we want. It just take the view and put it somewhere. The returning the view is the responsibility of our post list. So we use the combined latest. Remember what it does is that it will wait for these two observables to return at least one value. When they return at least one value, and after that, it will pass those two values to this view function of ours. This view function now takes two views and put them there. That's it. So that's what we do. Whenever these two return something, we put it in our view, render the whole view, create the whole tree again, and return it, which is then used in index.js without need to change anything, because we have the new view. So we get it. Now about the sidebar. The sidebar is static, right? It is waiting for the views. See, it is waiting for the requests we have made. It won't even render the sidebar till the requests are done. So what do we do about it? Sidebar does simply, it has a static view, just that brand, and we use observable.return. What do observable.return do? It just takes an argument and creates an observable which will just return that view and quit, complete itself. So it is waiting for the request. And how do we, say, avoid that wait? We don't need to wait for all of them for sidebar. We do a start with. Start with view. Tell it to start with the view, and return the view again. It is still waiting for the request, so I have to see. Oh, sorry, we don't have to start with hit this one. We have to start with this one. We start with an empty view. If we start with an empty view, nothing is rendered here. And the sidebar gets rendered. And whenever the requests are all fulfilled, it will render the main view as well. Not clear with this one either. So what we have at the moment, the styles I actually copied from theme, it's called a ghost theme, medium-like theme. I just copied the styles, why do I have to work? So what we have right now is we have a component system. We have our components quite isolated, right? So our component don't need to worry about other components. We have the isolated components. And we have a nice API to propagate the change that whenever components need to change, it will just update the view. We don't have to manually say that, update this li or do this, do that. That's where reactive parts comes in. And then we make these asynchronous calls quite composably using observable. And then we have this event system. The event system is quite simple. All thanks to the observables, we can just deal with the whole eventing model using just one event listener. So actually, let me give it away. This eventing system will actually not really work if we put events directly. Now if we do something like we put a click on this YAR, then our body will not see the click because YAR captured it. The event will not propagate down. So our event listener will not work at that point. So this is one thing we have to take care. If we are using this model, we have to just use this model. Doing something else will break it for wherever we use something else. Second thing is, figure it out. So shall we move to the next step? So our sidebar was empty. We want to fill it with something. And we got an error again. No, notice this error didn't break our app. It should usually because we are actually handling it. And what it says in the format data again, it will just pull it out. Sure. Menu of the main of the heritage. Say this view gets the arguments from here. We are calling the function here in the render. Now this combined latest operator, what it does is that it takes a number of observables and a callback in the end. So these observables, whenever they resolve, this view will get the value. What we are returning is this render function, not the view function. Sidebar is empty. So we want to add these widgets to our sidebar. So first is the filtering widget, that filter feeds by all or unread or read. Then a widget to fetch all the feeds again and to add a new feed, it will show this input field. And the list of feeds that we have subscribed to, to filter by them, not working yet, will work in next step. So how do we do that? So we have to add them all in our sidebar.js. So we create these three widgets as three separate components. There is this filter widget, then fetch and add widget. And then feed list widget. So first of the filter widget. So we'll just do the one widget. We don't have much time either. So the first step to do the widget is, this is readable. So this is how we create the widget. We just have a view which returns an untitled list of the three buttons that we have. And it just returns an observable, which will return our single view. Now we want to listen to clicks on it and change the class. When we use the clicks on the all, we move the active class to all, otherwise to read or to unread, read, then unread. So for that, we import the clicks by class from our events, the eventing model that we have set.  So whenever something clicks on this class, filter posts, any element with this class, this observable will respond. It will give us the event. We are interested in the target so that when we click on the unread button, we put the class on it. So we map it so that we get the right target. When we have the element on the next step, we do a side effect. Remember, this does not return anything. It does a side effect. Because we don't need to return anything here. We are just doing a side effect. Put a class here, put a class there. So what we do, we just select all the filter posts which have active class and remove the active class from them. Say map is like, you get a value. Map and flat map are same. Flat map is actually a combination of two operators. It is map and flatten. It will map it, say we have an observable of URLs. We map it, and we get the URL. Then we make a request. And we make that request in flat map because the request is not giving us a value. The request is giving us a promise. But we are interested in the value in next step. So the flat map will wait till that promise is resolved. And in the next step, we get the value. If we use map there directly, on the next step, we'll get the promise, not a lock. We made a request. We put that request in event loop. It is waiting till it is not finished. The next request gets to come again. And then it is waiting. Whenever they are resolved, the chain will continue. That is what we want, right? And if the request fails, an error will be raised. And we'll receive the error in subscribe. Flat map will make it go further the chain. That's what it does. So we converted the clicks event to this widget clicks. And then we remove, we change the class, basically. That's it. And we log it. Remember, we have to subscribe to it. If we don't subscribe to observable, it is lazy. It will not work until we subscribe to it. Because up to this, this is dead code. This becomes live when we subscribe to it. And we don't want to return this observable. So we just subscribe to it right there. And it will keep doing its job. Now, this is not really the right way of doing things. Because this do should only be used for debugging. We are doing it for side effects. Side effects are bad. What we should ideally be doing is that we, say, use this widget clicks in our view. And widget clicks should return the class name. Now, let us not confuse you further and forget it. So the last thing we are going to do. OK, let us keep it up to here. And further in the tutorial, if you guys are interested, you can go to this GitHub. And the whole tutorial is written in these steps. You can follow. At the end, we will have something like this. So I told you that we will use the local storage, not the local storage, the offline storage. So what offline storage does is that it will completely change the way we are dealing with data. Now we just get the request. We pass it to the feeds. But then we have to update the database, the index dv. And we have to update the views. We have two operations. We have to, say, take the request and do both. And if the request isn't passing, we have to take the data from local storage, offline storage. That is actually more complicated than it sounds when we actually get to implement it. So one way we can do it is the offline first. When we make the request, we fetch all the data and put it in a local storage. And we show the data from the local storage to our views. To our views render immediately from the offline data. And when the data comes, the offline data updates. Now we get another responsibility. That when the offline data updates, we have to update our views again. But we are doing reactive programming. It should be reactive. So in next steps, what we do is that we make the index dv reactive so that whenever something changes in the index dv, so this is a post dv. Whenever something changes in the dv, say, I clear the dv, the UI should change. We don't have to deal with UI after that at all. We just get the data and update the dv. That's it. And if we want to do something with feeds, we just do feeds.clear and our feeds are gone. So we are actually saving this data, the feed, in index dv. So for accessing index dv, because it has not so pretty API, we are using dexy.js. Dexy.js provides us hooks to listen to the events that when something is added to the database, when something is removed to the database. And we convert the dexy.js to observables because observables are reactive. And then we use those observables in our views. So what we basically get is that we want to remove this post, get its link, and we can do something like this. We just delete it from our database and the view updates accordingly. So if you guys are interested, you can check it on this GitHub. It's a tutorial. And you can actually use it's app. I do use it. So in the end, we also have to implement this one so that when we click a URL, we see the whole view. We use HTML to hyperscript parser for parsing the HTML to the virtual DOM. And then we have this button which deletes that view. And we come back here. So this is about it that we are going to do today. We're out of time, almost. So any questions? Say we don't subscribe to anything that we subscribe to only those things which we need for side effects, like these clicks. We don't want to return it. But feeds we want to use in this view. So what we do, we create the view using the feeds. All right? The feeds is in observable. View is in observable. Now view is composed of feeds. It consumes feeds. Then this view goes to the main view, the root of all. Evil. So that main view is then imported in our index.js and given to our renderer. Now our renderer subscribes to it. It gets subscribed in the end. Because once we have subscribed to an observable, the chain ends there. We don't want to end it. We want to use the chain further. So if any error comes anywhere along the chain, it will be handled here. We can handle the error accordingly. We can show, say, a warning that this thing has happened or anything without putting the warning messages all around the app. We can put them in the end. No, not always. It will happen only once. And we have this button, patch all feeds. The user clicks on it, and the feeds are patched. And this is the RSS reader. So it should be updating itself. So we can put an interval which will patch the feed. Any more questions? Of course, it handles it really well. So we can boost up. Say there is an operator called takeUntil. It will take the value until you don't know it. So the problem is that our view might not be present at the point. So we want to reject it. So there are operators. There is one takeUntil. We put the check in that. So if the check is true, then the promise, the further in the chain, we will get the value. Otherwise, the value just gets rejected. This is one problem with promises, actually. How do we reject a promise? We can't really do it that well. We can do it with observables pretty clean. So you can actually think of an observable as a promise which resolves more than once. It can keep resolving forever, or it can complete. Yeah? We all are. Sorry, I can't hear you. I am not getting you. Yeah? Yeah. OK, we are compiling only the ES6 syntax. Rx.js itself is compatible till Internet Explorer 6. So we don't need to compile the Rx. We are compiling the ES6 syntax. Normal. Yeah, it will be reflected then. We can compile it to that and don't need to then. Yeah, we have a watch so that we can compile this ES6 syntax, this arrow, and all that, to ES5. Any more questions here? The beauty of observables is that we can convert everything to an observable, an array, a value. So even the handler from index dv. We get the data from index dv, and we convert it to an observable. Then we use that observable to create our view. Like we do that like here. This post now here. The post now is coming from index dv. So index dv, when we get it, returns as a promise. This post is that one thing. And we map it to our views. This is how we link them together. Everything is an observable. We just say, do the plumbing. Get observable from here, another from there, plumb them, convert the data to the view, put it in the virtual domain. Done with it. Any more? Yeah? Will we monitor, say, we have an array, right? Array, by definition, is the snapshot at one time. When it updates again, we have to create a new array. We don't update an array. No, it won't work that way. Say, we have converted that into an observable. So it can watch for it. If it tells the observable that I have changed. Array can tell anyone that I have changed. Event can. Event is basically, that is what it do. When we have an event, it says that, hey, I have a new value. So our observables are reactive in that case. Yeah? I don't really know that. I don't know. It's in JavaScript. I will check it. Any more questions? OK, then. Thank you, Vipur.


Welcome traders to another intraday wave analysis session with me Patrick Munley want to draw your attention to a sequence That's developing here in the euro Swiss from the hourly time frame. The euro Swiss actually reversing From the weekly trend line support highlighted in last week's live analysis session The most outside reversal candle from that trend line support So we're now looking at the hourly time frame looking for an entry on the long side. We've got a Potential way three high in place This initial leg off the lows That's way through subdivided nicely into five waves and we now have a ABC pattern developing I'm looking for a test of the equality objective versus the b-swing high 109.52 down to the weekly pivots 129.22 and the equality objective 109.20 Well, it's reversal pants. They're set long positions targeting and move up to 109.70 as always traders plan the trade manager risk


Hello and welcome to the session on Unified Modeling Language. In this video, we learn how to draw class diagram and object diagram for a software system to be designed. At the end of this session, students will be able to understand building blocks of UML, analyze things, relationships and diagrams in UML, and draw class diagram and object diagram of UML representing designs to be used for software development. You have already learnt about OMT i.e. Object Modeling Technique in earlier videos. Now pause the video for a while and try to answer this question. What could be another approach to model a system apart from OMT? Here is the answer. It is the Unified Modeling Language i.e. UML. The contents we are going to cover are building blocks of UML, class diagram and object diagram. To start with, these are three important blocks in UML namely things, relationships and diagrams. Things are the abstractions that are first class citizens in a model. Relationships tie these things together and diagrams group interesting collections of things. There are four kinds of things in the UML namely structural things, behavioral things, grouping things and annotational things. Starting with the structural things. Structural things are the nouns of UML models. These are the mostly static parts of a model representing elements that are either conceptual or physical. In all, there are seven kinds of structural things. First, a class is a description of a set of objects that share the same attributes, operations, relationships and semantics. A class implements one or more interfaces. Graphically, a class is rendered as a rectangle, usually including its name, attributes and operations as shown in figure with three different compartments. Second, interface is a collection of operations that specify a service of a class or component. It describes the externally visible behavior of that element which might represent the complete behavior of a class or component or only a part of that behavior. Graphically, an interface is rendered as a circle together with its name. An interface rarely stands alone. Rather, it is typically attached to a class or component that realizes the interface as shown in figure two. Third, a collaboration defines an interaction which represents the implementation of patterns that make up a system. Graphically, a collaboration is rendered as an ellipse with dashed lines, usually including only its name as in figure three. Next, a use case is a description of a set of sequence of actions that a system performs that yields an observable result of value to a particular actor. Graphically, a use case is rendered as an ellipse with solid lines, usually including only its name as shown in figure four. Next, an active class is a class whose objects own one or more processes or threads and therefore can initiate control activity. It is just like a class except that its objects represent elements whose behavior is concurrently with other elements. Graphically, an active class is rendered just like a class but with heavy lines usually including its name, attributes and operations as shown in figure five. The next, a component is a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces. Graphically, a component is rendered as a rectangle with tabs usually including only its name as in figure six. The next, a node is a physical element that exists at runtime and represents a computational resource. A set of components may reside on a node and may also migrate from node to node. Graphically, a node is rendered as a cube usually including only its name as in figure seven. Behavioral things are the dynamic parts of UML models. These are the verbs of a model representing behavior over time and space. In all, there are two primary kinds of behavioral things. Number one, a message is rendered as a directed line almost always including the name of its operation as shown in figure eight. Second, a state is rendered as a rounded rectangle usually including its name and its substates if any as shown in figure nine. Grouping things are the organizational parts of UML models. These are the boxes into which a model can be decomposed. In all, there is one primary kind of grouping thing namely packages. A package is a general purpose mechanism for organizing elements into groups. Structural things, behavioral things and even other grouping things may be placed in a package. Graphically, a package is rendered as a tabbed folder usually including only its name and sometimes its contents as shown in figure ten. Annotational things are the explanatory parts of UML models. There is one primary kind of annotational thing called a node. A node is simply a symbol for rendering constraints and comments attached to an element or a collection of elements. Graphically, a node is rendered as a rectangle with a dog eared corner together with a textual or graphical comment as shown in figure eleven. There are four kinds of relationships in the UML namely dependency, association, generalization and realization. A dependency is a semantic relationship between two things in which a change to one thing which is the independent thing may affect the semantics of the other thing, the dependent thing. Graphically, a dependency is rendered as a dashed line possibly directed and occasionally including a label as shown in figure twelve. An association is a structural relationship that describes a set of links, a link being a connection among objects. Aggregation is a special kind of association representing a structural relationship between a whole and its parts. Graphically, an association is rendered as a solid line possibly directed occasionally including a label and often containing other adornments such as multiplicity and roll names as shown in figure thirteen. A generalization is a specialization-generalization relationship in which objects of the specialized element that is the child are substitutable for objects of the generalized element, the parent. In this way, the child shares the structure and the behavior of the parent. Graphically, a generalization relationship is rendered as a solid line with a hollow arrowhead pointing to the parent as shown in figure fourteen. A realization is a semantic relationship between classifiers wherein one classifier specifies a contract that another classifier guarantees to carry out. We will encounter realization relationships in two places between interfaces and the classes or components that realize them and between use cases and the classes or components that realize them. Graphically, a realization relationship is rendered as a cross between a generalization and a dependency relationship as shown in figure fifteen. Next, a diagram is a graphical presentation of a set of elements most often rendered as a connected graph of vertices, those are things and arcs which are relationships. The UML includes nine such diagrams namely class diagram, object diagram, use case diagram, sequence diagram, collaboration diagram, state chart diagram, activity diagram, component diagram and deployment diagram. A class diagram shows a set of classes, interfaces and collaborations and their relationships. These diagrams are the most common diagrams found in modeling object oriented systems. Here is an example of a class diagram. As we can see, there is a class named as company which is generalized into department and office. Each class can be seen with three different compartments, first with its name, second with its attributes and third with its operations. Department is next connected to person, person is associated to contact information and personal record and office has a headquarter. The different list of attributes and operations can also be seen in this class diagram. Next is the object diagram. An object diagram shows a set of objects and their relationships. These diagrams address the static design view or static process view of a system as do class diagrams but from the perspective of real or prototypical cases. Here is an example of an object diagram which is drawn for the same class diagram shown earlier. We have instantiated each of the classes namely company, department, person and contact information. As you can see, C is a variable instantiated for company, D1 and D2 as well as D3 are the departments with names corresponding to sales, R&D, US sales respectively. Person instantiated into name is equal to Erin employee ID 4362 and title equal to VP of sales. So we can see how the attributes are given values in every object. Here is a time for think and reflect. Pause the video for a while and try to answer this question. A class is divided into which of these compartments and the answer is all of dimension. Because as we have seen in the example class diagram, each class is represented as a rectangle which has three different compartments. First for its name, second for the list of attributes and the third for the list of operations. Thank you.


Various groups of women with over 60 female politicians who contested at the 2023 elections converged in Kaduna to strategize for a successful outcome ahead of the 2027 General Election Details and Disciples. Gender and Constitution Reform Network, a women advocate and civil society organization in the Northwest region noted that barriers against women's political success as a result of manipulation and marginalization in a political space. They stated this in a communique issue that at the end of one day people's hearing, the Northwest coordinator, Dr. Lydia Umar, says despite the region's 23% total population of Nigeria would have been women, it can only boost of two elected women in the 2023 election. Out of the total of 15,307 persons that contested for the office in the just concluded, in offices in the just concluded, 2023 elections nationwide, only 1,553 are women. Women in the Northwest have come of age and are now ably educated and qualified to also take driving seats in the politics and governance of the region. That religion and culture have been manipulated and instrumentalized to keep women out from participating in active politics. The group lamented that political parties conspired to marginalize women from realizing their aspirations to elective positions. Women have very little economic power, therefore the flagrant monetization of the political space knocks out women. Major political parties do not give women platforms to contest and therefore navigating political party primaries is near impossible. While calling on religious leaders to teach the truth irrespective of faith and culture, they appealed to women folk to seek economic empowerment and equip themselves as politics in Nigeria is capital intensive. On women to start early, girls should also be encouraged to take up leadership positions in school and youth associations and other positive clubs. They must be mentored. The education of women and girls must be pursued in order to equip them to engage with issues. Women need to rise up in solidarity with each other if they must achieve their goal. According to Leader Omar, out after a total of 15,307 persons that contested for office and it just concluded 2023 elections nationwide, only 1,553 are women. So you get notified about fresh news updates.