Today we will discuss some of the Graphical ModellingTechniques used in the process of Engineering System Design. These are some of thequalitative modeling techniques, widely used in industry for the different stages ofdesign process.In the last few classes we discussed about the various processes in system design, and wefound that there are many tools to be used at various stages; especially when it comes tothe functional modeling, architecture development, interface development, etcetera. Weneed to think of various modeling techniques so that the process becomes much simplerand then gives a much better idea about the whole process what we are doing.So, in this lecture and then the coming few lectures I will discuss about some of the verycommonly used methods for modeling of system as well as some of the processes in thesystem design.(Refer Slide Time: 01:16)
The main techniques what we are going to discuss are the modeling techniques the firstone is basically known as the data model. It is the relationship between data entities. So,we have various entities in the system and there are lots of data exchanges between theseentities. So, we need to model this data relationship, basically the input outputrelationships between the entities and we use the data modeling techniques to do this.The mainly used data model techniques are the entity relationship diagrams and higraph.We will go through these methods ER diagrams and higraph, but before that let meexplain the other two methods, where we use for modeling the other one is known asprocess modeling.So, the first one was data model which actually gives the relationship between the dataentities and in the process model, we discuss about the modeling of processes basicallythe flow of functions in the system. It identifies the processes what processes done andwhen it is done and so on. So, here in the process modeling, the focus is on identifyingthe flows between the entities. So, especially in the functional modeling, we need toidentify what function is processed by which entity and how this function flow is takingplace. So, in order to do that we use the process model and here we have differentmethods; one is known as a data flow or method the other one is known as an N2diagram these are somewhat similar to the IDEF0 diagram we already discussed, butthese are alternative methods for modeling of the process within the system.The last one is known as the behavior model. In behavior model we look at thecontrolled and activation of various processes in the system. So, how is it controlled andhow the flow is taking place, what kind of control input is needed those things areactually modelled using the behavior model. Especially the termination of systemfunctions these are modelled using the behavior model. The methods commonly used arethe FFBD that is the function flow block diagram, then behavior diagrams and petrinets.So, all these are used to model the control activation termination of system functions atvarious stages. So, this is needed to identify, what kind of control action we need toprovide and when actually a particular function terminates and what kind of controlinputs are needed and what kind of processes are taking place parallely.So, are these can be modelled using the behavior models. So, these are the threeimportant modeling techniques will be discussing in this lecture. So, we will start with
the data model which is the relationship between data entities. So, we will start with theER diagram or the entity relationship diagram.(Refer Slide Time: 04:02)
The entity relationship diagrams, which models the data structures or relationshipsbetween data entities. So, here the relationship between the data entities are modelledusing the entity relationship diagram and an entity is defined as a class of real similaritems like people, computer, books etcetera. So, these entities we model the relationshipbetween this entities using the entity relationship diagram and how do we create ERD.So, here these created basically the entity relationship diagram are created by identifyingthe entities. So, we identify all the entities in the system, and then we identify thesignificant events.So, what are the significant events taking place and then analyze the nature ofinteractions and then draw the entity relationship diagram. So, as I mentioned it isbasically explains the relationship between the entities. So, in order to draw the data flowdiagram, we need to identify the entities and the relationship between the entities. Andonce we identify this interaction between the entities we can actually draw the entityrelationship diagram. I will explain some of the methods used for entity relationshipdiagram to draw the diagram. So, let us go to the board and then see how the entities arerelated or represented and how the relationships are explained using entity relationshipdiagram.
So, in entity relationship diagram, all the entities are represented using a square block.So, all the entities are represented using a square block.(Refer Slide Time: 05:37)
So, this is the entity and the relationship between two entities. So, we have another entityover here, the relationship between these two entities are represented using a diamondshaped box. So, this is the relationship and it is connected like this. So, if you have morerelationships, you can actually draw more diamond shaped boxes to represent therelationship. So, this is the basic entity relationship structure. So, here as you can see wecan have many entities and many kind of relationships. So, the entities are normallyrepresented using the square blocks and the relationship is represented using diamondshaped boxes. Another way of doing this is basically you can instead of having thediamond boxes we can actually have directed the relationships, where we simply showan arrow a directed arrow to represent the relationship.So, this is entity 1 this is entity 2 and we can have the relationships written over here R1R2 R3 the relationship. So, in this case if you are using the diamond shaped box torepresent the relationship, then we do not use the arrows, but when we are not using therelationship we will use arrows to represent the directional relationship. For example, wetake a case of a customer making deposits, how do we represent the relationship betweenthe customer and the money. So, customer is an entity here is a very simple example. So,we take the customer and money at two entities. So, as we mentioned an entity can be
anything it is a man machine material or any other thing, which can actually berepresented.So, this is one entity and this is another entity and when a customer makes a deposit. So,we can actually write down the relationship like this. So, here actually customer depositmoney. So, that can be one relationship customer can deposit money and the other one iscustomer withdraws money maybe another relationship of course, you can have manythis kind of relationships and transfer money. So, these are the three relationship we canidentify customer deposit money customer withdraws money customer transfers money.So, this actually shows that these are the kind of relationship a customer can have withmoney and that actually represented using a graphical methods. So, it is model of aqualitative modeling technique where we represent the relationship between thecustomer and the money or between different entities.We can have different relationship depending on the scenarios, we can actually identifymany other scenarios like customer wants to make a print out of the account or theaccount statement, then the entities will be different here the customer will be the entityhere the entity instead of money will be having a different entity. And the samerelationship can be represented using the directional arrows also. So, instead of thediamond boxes you will be having the directional arrows.(Refer Slide Time: 09:38)
So, these are the two entities. So, this is another way of representing the same ERdiagram customer money and here you will be having the deposit at the relationshipdeposit and transfer or withdraw.So, we can represent the relationship is either using this methods or using this method inboth cases, you will see that there is a relationship here the arrows are shown here in thiscase, but in this case arrows are not shown. This is the way how the entity relationshipdiagram is drawn. These are very simple cases then there is methods were used for a longtime to represent the relationships. And here you can actually have different kinds ofrelationship also you can have a one-to-one relationship between entities or you can havea one to many relationship or you can have a many to many relationship between theentities. So, that also can be represented using the entity relationship diagram. So, hereyou can see if you have two entities like a office manager and office.Suppose these are the two entities then we can have a relationship here, office managermanages the office or heads the office. So, this is the relationship between the entities.So, this is entity 1 office manager and this office is the entity 2. So, here you can have arelationship office manager heads office. So, normally we will have a one-to-one
relationship for this. So, it is one office manager heads one office. So, that is the one-to-one relationship in entity relationship diagram. So, in some cases like you can have again
an office or we can have take another example for the same one-to-one diagram one-to-one relationship is vehicle registration number of vehicle this is again an example for
one-to-one relationship.So, registration number assigned to vehicles. So, here you can see that one registrationnumber is assigned to one vehicle. So, again this is a one-to-one relationship. So, the
relationship where is only one entity, related to one entity that is represented by one-to-one relationship. And if you have one to many relationship then we will be representing
in a different way the entity relationship diagram will be almost the same except that wewill be having a relationship shown with the numbers over there. So, one to many isnormal represented as 1 to M and this will be sometimes at the present N to M as manyto many that is N entities related to M entities.So, here you can take an example for the one to many relationships. So, if you have adepartment suppose we have concerning a department in an engineering college. So, we
can see that department employs sorry. So, this is again entity say department employeesstaff. So, here you can see that one department will employ many staff. So, this is a 1 toM relationship similarly we can have one person you can have a person owns vehicles.So, you can have that person as an entity owns as a relationship and vehicles has otherentity. So, here again the relationship is that one person can on many vehicles. If it isonly one vehicle then it would be one person owns one vehicle, but in this case oneperson can on many vehicles.So, the relationship will be a 1 to M relationship in the entity relationship diagram that isthe 1 to M relationship. The same way you can actually have a many to manyrelationship also, in many to many relationship you will be having many entities overhere interacting with many other entities through the a single relationship. So, if you takethis as an example we can see here.(Refer Slide Time: 15:10)
You take the example of reservation system or the students registering to a two courses;the students are an entity then courses. So, you can see that there are M students canregister for N courses. So, this is registration for courses; so registration as an entity I asa relationship. So, M students register for N course that is M to N relationship. If youtake a single student then it will be 1 to M relationship one student registering for Ncourses then it will be like a 1 to M relationship.
So, in this case when you take M students they register for N courses. So, M studentsregister for N courses in a say a many to many relationships. So, these are known asmany to many relationships. Similarly you can see the ticket booking of by passengers.So, passengers reserve seats. So, flights or trains, you can see again this will be an M toN relationship, you have M passengers reserving seats for N flights; so again M to Nrelationship.So, if you take a single passenger, then it will be a N to N relationship otherwise it willbe M to N relationship. So, you can see here the ER diagrams can represent variousscenarios, basically the relationship between various entities are shown here and in thisentity relationship we can actually represent the entities as rectangular boxes andrelationship as diamond shaped boxes, and then can have this relationship either using adiamond box relationship or you can have a directed arrows. So, when you are usingdirected arrows, we do not use the boxes over here we describe the relationship asR1,R2, R3whatever may be the relationship.So, these are some of the examples for the ER diagram simple ER diagrams and in ERdiagram you can have one-to-one relationship or one to many relationship or N to Mrelationship. So, any relationship can be represented using the ER diagram and we sawsome of the examples where you can have a one-to-one relationship or 1 to Nrelationship or N to M relationship. So, these are the simple ER diagrams, now if Icombined these relationships 1 to N and N to M relationship I can show you a simpleexample how do we actually combined these things to make a scenario. So, take theexample of a salesman basically nowadays you can see lot of salesmen come directly tothe houses and do a direct selling. So, if you take an example of a salesman.
(Refer Slide Time: 18:29)
So, if you consider a salesman as an entity. So, a salesman will actually serve thecustomers or the when I visits the homes or the shops were of whatever maybe thesituation. So, he serves customers, we can take customer as another entity. So, here youcan see this is a 1 to M relationship one salesman will serve M customers one salesmancan serve many customers. Therefore, this will be a 1 to M relationship and then onecustomer will make base many orders. So, a customer places. So, again he can see thatone customer now we are taking only one customer here, one customer places M orders.So, he is again a 1 to M relationship, because the customer can make many orders andmany orders. So, the once the salesman is taking the order. So, he will be taking orderfrom many people. So, finally, he will be getting many orders with many items.So, he will actually list all the orders, this is the relationship the orders are listed together.So, he will be getting list with the many products; so the products that of final productrelationship, the list will be having many products. So, he will be having N list or I amusing N for to say the many relationship. So, N list with M products; this is again a manyto many relationship. So, from multiple customers will be getting orders and there willbe N list with M products and this will be to the store. So, this list will go to the stores or.So, here this is the warehouse entity. So, all these list will go to the warehouse. So, youwill be having when one warehouse where the items are stored.
So, you will be having one warehouse with M product and when the order placed a placeorder. For the M products now order will be placed to one warehouse. So, this is therelationship from the salesman, one salesman serves many customers. So, a 1 to Mrelationship for the salesman to customer and then one customer places many ordersmany orders are listed in to the M products. So, M products are listed in this M to Mrelationship between the order and the products there are N list and M products and theseM products are ordered to the one warehouse. So, one warehouse will be serving all thecustomers and then again you can see that one warehouse sends the product to thecustomer, individual customers. So, supply again products. So, you can see onewarehouse supplying N products.So, this is the way how the flow is represented the relationship not represented using ERdiagrams of course, this is a very simple example, I have taken a very simple example toshow the utility of the ER diagram to represent the data flow in a system. We canactually extend these two complex systems also. So, we will see some of the complex ERdiagrams how the simple ER diagrams can be actually replaced with the complex ERdiagram. So, some of the things will be simplifying instead of showing all therelationship in the diamond boxes, we will try to represent them using directed arrowsand when we do this you will be getting the complex ER diagrams, which can actuallyrepresent many complex relationship between the entities. Now let us look at one of thecomplex ER diagram.In complex ER diagram what we try to do is to represent the subclass relationship classor subclass relationship.
(Refer Slide Time: 23:19)
Class subclass relationships are represented using at M called “is-a” relationship. So, asubset is represented as is a subset of other one. So, this is how we actually represent thesubclasses in complex ER diagrams. We will take an example of system design itself weknow that system design is a complex process. So, the system designs itself there arevarious entities in the system design. So, we will try to identify the relationship betweenthis entity is using a complex ER diagram. Now here you can start with the variousentities. So, here the entities are represented the using oval shape instead of the squareboxes because again this is complex one. So, you need to have many entities. So, we willtry to simplify it. So, the ORD will give you the requirement. So, the relationshipbetween ORD and the requirement is represented by this.So, this is the requirement. So, the relation between ORD and requirement is that, ORDthe documents the requirement. So, this is an entity ORD is an entity requirement is anentity and the relationship is given by the document. So, ORD documents therequirements and then that is another entities, you can write it as a trade of requirement.Now, we can see that trade off requirement is a requirement. So, the relationship is givenlike this between these two entities, the tradeoff requirement is a subclass of therequirement and this subclass is represented by a relationship known as is a relationship.So, you can see trade off requirement is a requirement and ORD documents are therequirements.
Similarly, you can have many sub classes for the requirement because this is just one ofthe requirement you can actually have here in the relationship for the system widerequirement as another entity again this is a relationship. So, here system widerequirement is a requirement similarly there are test requirements, this is again is arelationship. So, test requirement is a requirement, then you have the input outputrequirements is a requirement. So, these are all the subclass of requirements trade offrequirement system wide requirement test requirement input output requirement and thenthe state wide requirement again you can write the relationship.So, here if you have some other requirement like decide software requirement. So, insome cases you may be having a specific requirement of software. So, the decidesoftware requirement will be another requirement, but then again it is a part of state widerequirement. So, we can write it as the decide software requirement is a system widerequirement, it is a subclass of the system wide requirements.Now again you can actually have another relationship can be identified here between thetest requirement and the system wide requirement. So, the test requirement can be tracedto the. So, this is the relationship between these two entity. So, this is a test requirementis an entity system wide requirement is an entity. So, we can have a relationship betweentest requirement and system wide requirement traced to; that is the test requirement canbe traced to the system wide requirement.Similarly, the test requirement can be traced to the input output requirement also.Basically the test requirement comes from all these systematic requirement input outputrequirement and all other requirements. So, we can always have a relationship this istraced to the input output requirement. And then we can have another entity here that isthe derived input output requirements. So, derived input output requirement then wehave a in a relationship it is a subclass of input output requirement.So, derived input output requirement is a input output requirement or it is traced comingfrom this say subclass of this requirement therefore, you can actually write it as a is arelationship. So, the subclasses are represented I say using their relationship is arelationship, and the other cases we have used the trace to relationship or whatever maybe the relationship will be represented as trace to or documents like that. And again inthis you can see that the system wide requirements.
So, you have the main system here. So, this is the system as an entity. So, the systemwide requirements can be traced to the system. So, again he had say sorry this is systemwide requirements are traced to the system. So, this is a trace to relationship and then thesystem performs the functions. So, we know that there are many functions in the systemand the system basically tries to or system is basically designed to perform this function.So, the system performs the functions, that the relationship is here perform. The systemsperform the functions and of course are these can be traced to the functions. So, here thisis relationship is traced to. So, again the input output requirement can be traced to thefunctions, derived input output requirement can be traced to the functions.Basically, we know that the functions are there to provide these requirements or we thatis why we can actually trace these to the functions. Then again we know that there arefunctional decompositions, they are actually different functions are identified this is afunctional decomposition. So, this actually contains all the functions the functionaldecomposition will contain all the function. So, the relationship here is that it containsthe functions. So, that is a relationship between these entities. So, all those shown in thiscircle or the oval shape or the entities and the relationship are expressed using thedirected arrows.Now, the system will be having many components to provide the function. So, this is thephysical architecture we are talking about the components and the subsystems, and thencomponents will be having we can actually have the relationship between system andcomponent a system is built from the components. So, we can have the relationships herethe system is built from components, the relationship is built from. So, here you can seethe components actually form a system. So, system is built from components, and wehave the smallest item in the physical architecture which is known as the configurationitems and we know that configuration item is a subset of components. So, this is arelationship.So, configuration item is a component. So, this is a subclass or configuration item is asubclass of component, that is why we have a is a relationship here. And then we havethe physical architecture something similar to the functional architecture, we have thephysical architecture and again we have the relationship components are part of thephysical architecture. So, it actually physical architecture contains the components ofcourse; it can be components or the subsystems. So, we write the relationship as physical
architecture contains the components and then we have the interfaces as another entity;here the interface is basically used to connect the components.So, we say that components. So, the arrow should be in this direction. So, therelationship is connected and then again you can have interfaces with between systems orsystem connects with the external systems. So, we can have a interfaces connecting thesystem also. So, relationship between interface and system again is connected and ofcourse, interface will perform many functions. Therefore, there is a relationship interfaceperforms functions and again there will be interface items that basically the physicalelements of interface items. So, this actually interface contains items the configurationitems it can be components or the software or any other configuration item which is usedto form the interface these are the items and the functions are produced by this items forthe interface. So, this is actually functions are transformed by the interfaces.So, that is the relation between items and transforms; and then we have the externalsystems as another entity external system another entity, and which actually performs theany functions and here again interface is connected to the interface. So, the interfaceconnects the external systems. So, the external systems again the interfaces are used forconnecting this. So, you have the external interface external system connected by theinterface and again there are external system perform the decompositions and then youhave this last item is the functional architecture which actually documents the functionaldecomposition. So, that is the relationship here is documents. So, this is the complex ERdiagram for system design.As we can see here as now the system design is a complex process there are manyentities involved in the system design and therefore, we need to represent them using therelationships what we are trying to do is to identify all the entities and then try to seewhat kind of relationships are existing between these entities and as I mentioned thereare different kind of relationship between the entities. So, we try to identify therelationship as well as the class or subclass relationship and the subclass relationship isrepresented using a is a relationship. And all
other relationships are not using directedarrows as we can here if you take the system as the main entity you can have there aredifferent relationship between the entity system as well as the requirements.
So, you have there are different requirements the input output requirement derivedrequirement all can be traced to the functions of the system because the system needs toperform the functions and therefore, we have many requirements identified from thereand apart from the function the system has got some system wide requirement especiallyin terms of technology and other requirements, that is where the system widerequirement can be traced to the system, similarly there are requirements for desiredsoftware or hardware. So, that can actually be considered as a subclass of the systemwide requirement.Therefore, you are getting an is a relationship as part of the relationship between theseentities; and ORD is the document. So, originating requirement document we identify orwe prepare and the system design, when we are ready with all the system requirementsand other identified functions and needs. So, the ORD basically documents all therequirements and again you can see these are all the requirement, which are the all theseare subclass of the requirement that is why the relationship between these entities and therequirement is a relationship because it is a subclass of this