Overview: UML® (Unified Modeling Language™) and SysML® (Systems Modeling Language™)

[Music] let's talk a little bit more about two of the main modeling languages if you are at my earlier presentation I talked about two general modeling language communities that cover a lot of the major modeling languages standards in OMG the UML family and the BPMN family in the UML family obviously we start with UML but one of the most popular languages that have been built on top of UML is system l the system's modeling language so we'll talk about both of those now in introducing the language there's sort of the question about whether I talk about the language or I show you the language I'm from the school of thought that you don't learn a language unless you use it well we're not going to actually do a hands-on exercise here but at least I want to all right JD is going to give you exercises after each of my slides so you could but at least I wanted to show you the language so I will introduce the language by running through a couple examples which means we're gonna have to get down into actually looking at these diagrams hopefully this screen is big enough but you're not gonna be able to see all the details but I wanted to point out to you some of the key features of both of these languages and how they're used in realistic examples in the time that we have now how many of you here are actually modelers who have modeled say in UML right I remember doing hands before so some of this will be familiar to you but you may learn a few things about parts of UML that you haven't used just much how many people here have done sysml modeling fewer well that's good there's this little example is a little more extensive and and there may be some things interesting there as I'm going through feel free to stop me if you have questions because it's important that you understand now if there's gonna be an extended discussion we'll probably put that off till the end but if it's a question of something that you don't understand just raise your hand and we'll clear that up all right so the unified modeling language this quote is from version 0.9 in 1996 this is actually just before 0 1.0 was submitted to the OMG now many of you have used 2 ml may know that the history of UML is a development that comes from the work of who and three guys were known as the three amigos of modeling Grady Booch Jim Romani Vario Crimson they all had developed different methodologies and notations for object-oriented software development specifically this came out of work started even in the 70s but especially in the 80s and by the 90s you had these different groups all doing similar things but not able to communicate well with each other because they were using different notations and terms and concepts in some cases but ultimately trying to do the same thing so Grady actually started this and then Jim Rimbaud joined him and eventually very occup señal at rational software corporation and that the time of 0.9 you know this was called unified modeling language for object-oriented development that was the big thing at the time it was very specific to object-oriented software development the purpose was really to unify the boot OMT and oose methods the Booch method is Grady Booch is method OMT is Jim rumba and he had a number of collaborators I call them at and all but that's always Jim rumba at also and Yvonne oxen was the oose as I matured in software engineering was his method so really when it says unified their intent here was not to unify everything in the world the unified initially was just the unification of the major object-oriented methods well by the time we got the version 1.1 remember this is the first adopted OMG standard for UML from the UML summary version 1.1 in the preface it says the unified modeling language is a language for specifying visualizing constructing and documenting the artifacts of software systems that seems consistent with three amigos but then it adds as well as for business modeling and other non software systems so right from the beginning that the scope had expanded now if you look later on though in the scope of UML in version 1 1 it says UML is the language are specified in constructing and visualizing and documenting the artifacts of a software intensive system so it was still intended to be scoped at this point for systems which maybe weren't just software systems but it involved a lot of software and to this day Grady Booch is now a fellow at IBM and enjoying his life in Hawaii I don't think he leaves Hawaii unless somebody pays him a lot of money because but he still says that that is what UML is for it is for specifying software intensive systems and that's really what it was designed for originally but if you look now in version 2 v 1 which is the latest version you'll see a scope that is surprisingly quite similar to what was in version 1 1 in the preference I showed this before that the objective UML is to provide System Architect software engineer software developers with tools for analysis design and implementation of software based systems as well as for business modeling and similar processes there is nowhere in the spec now with UML 2 a limitation to software intensive systems it actually it completed the expansion of the scope that was good and bad as with any version 2 when you expand the scope too much you do get a much bigger and more complicated product on the other hand it has provided a basis a very rich basis for doing things like sysml and Marte and the other profiles that would not have been possible with UML one so let's look at an example here this example is going to be an online shopping system because everybody these days has used some sort of e-commerce system so let's say we're trying to specify an online shopping system that we're going to build well first thing we want to do this is a use case diagram that specifies the requirements now obviously this is just a small piece of it scoped down but the basic idea here is that we have a model that represents the functional requirements of the now there's ways to annotate this to get other requirements non-functional requirements performance requirements but really this model is intended to do functional requirements we will see later on that sysml has a richer capability for modeling a wider range of kinds of requirements but for functional requirements a use case model is very good and as I mentioned this morning there is actually this graphical modeling notation for it the key concepts here you have the system outside the system you have these actors these little stick figures now actor is actually probably not the best name because this doesn't represent the actor it actually represents the role the actor plays but some people don't quite get with use cases so it doesn't represent a specific customer or represents the role of a customer and somebody can be a customer and also be something else but when they're acting as a customer the system has certain requirements relative to that external actor the whole point of use case modeling is the specification of an interaction of the system with an external actor and a good use case specifies an end to end interaction provides a measurable benefit to the primary actor that's why it's your requirement if it doesn't provide a benefit to an actor the system isn't required to do it because there's no point now I said primary actor because you can see on the other side there are what sometimes they're called secondary actors the system interacts with them but they are there to really carry out the behavior that provides benefit to the customer in this case the primary actor things like credit card providers ship or authentication provider those provide services to the system those are also actors so this is the basic UML approach for defining the functional requirement to the system you notice that these use cases can have relationships between them also now it is often the case that people don't use these these are sometimes considered advanced but it's actually I think a very nice and very rich way to graphically present the behavioral connections between the requirements of a system the two main ones I've shown here are extended include the extend relationship is not well understood but it's very useful it's an event-based triggering mechanism so if I'm shopping at some point I might want to do a search and based on that search or might decide to put something in a shopping cart and then check out those are things that are not that defined process but are decisions that are made are events that are made by the customer that trigger other behavior in the system there's also the include relationship which is a more typical call like relationship that means the behavior of one use case included in the other when I check out have to authenticate in order to check out from the system so let's put that together so that's a sort of nice overview what the use case diagram is provides a nice overview of all the facets of the behavior of the system what I'm going to do now is show you how we can actually define that behavior in more detail now there's a number of ways of doing that I can go in and show it for each use case and then use the diagram to fit them together I kind of like doing that but here I'm showing an example that actually puts all those pieces together and shows a complete process for the shopping use case behavior so when a customer is shopping they start out well first of all these vertical swim lanes you can see why they're often called swim lanes technically their activity partitions they indicate the agent that is carrying out the specific actions so this is an activity diagram that shows actions being carried out by the system and the actors around the system so this is a high-level process showing how the actors interact with the system it starts here at this initial node and then we've got a set of actions those rounded boxes or actions or steps in the behavior so you can see that what happens here is that the customer comes in chooses an action to perform either searches or browses if they're searching they either find or don't find the thing they're searching for if they find a product they can then either view cancel the review of the product or they can select the product they get authenticated it gets added to the shopping cart they can view the shopping cart and then they can checkout once they check out it comes over and approves the credit card charge that can either approve to decline and then if it's approved they both get a success notification and the shipment gets prepared all right so it's a fairly typical flow we've got the actions we've got arrows between them which I call control flows which are the sequencing of the actions then we've got these things called control nodes which are basically describe how the control flow may be controlled so a decision note defines alternative flows based on some test in this case the credit card approval a fork node split the flow into multiple concurrent Forks so if you view the success notification at the same time it prepares the shipment to be shipped by the shipper and then the merge node over there brings multiple flows together there are a number of other nodes join nodes there's quite a bit but this gives you a basic idea of how you describe the flow of an activity in your mouth so now we have the idea of the requirements the overall process that this system is supposed to support what we're going to do is talk a little bit more about the design of the system big system you need to break it down so you break the system down into substances between two components this is a composite structure diagram that shows the overall structure of the composition of the system we have a component which is an encapsulated part of the system so breaking the system down into these components we have within this overall in line shopping system a search engine component and inventory management component online shopping component order management authentication and customer management and that's a design decision to break it down in this way what does it mean for these to be encapsulated well it means we are going to talk about the interfaces the important thing when we decompose is that we define how those pieces communicate through specific interfaces from a design point of view this lets us then have teams that work on the individual components of the system they can work somewhat independently with well-defined interfaces between the components the interfaces are defined on ports which are represented by these little boxes so each component has a set of ports which is interaction point through which the component communicates and the lines that connect those parts ports are called connectors the connectors provide the path for communication so we can see here that the search engine component communicates for the inventory management component which communicates the order management component the online shopping component not surprisingly talks to authentication and order management etc but we do not have the inventory management component caught talking to the customer management component that's not the way we design the system that only has to happen through order management so the port's have interfaces on them so the port can have actually two kinds of interfaces a provided interface and a required interface and the interfaces can be used on multiple ports don't have that example here but this is a notation for a port which has an interface that's not connected so the little lollipop represents the interface the interface is actually the thing that declares the service is provided by the component I haven't gone into the detail but I can actually do a model that shows on the on the interface what the communication happens across the interface the port then says for that component this is the point where I am either providing or on the other end requiring that interface so here we have a required interface so online shopping provides the online shopping interface that's external that's we're going to connect up say a UI or something we don't show it connected right here and on the back end we have a connection to some sort of account management component that I haven't connected up yet all right so that's the structure defined interfaces interfaces are on ports and ports are on components and then the components are connected and they provide together the collaborate divide the behavior of the system and how do they collaborate all right so this is a little hard to read but not as compact as I could get it to show the entire process this shows actually a left off with annotation because it was getting too big but this shows the architectural realization so that all that component decomposition is part of the system architecture the architectural design what we want to say is well I know I have this overall process of how the system is supposed to provide a benefit to the customer I've decomposed it well how do I allocate those requirements down to those subsystems how do I make sure that those systems can interact in order to provide the overall behavior of the system I can do that by modeling that interaction one way to model that is with a sequence diagram cut off so this sequence diagram shows the shopping architectural realization so what we have here is a set of what are called life lines these are similar to the swim lanes on an activity diagram but a sequence diagram rather than focusing on the detail of the actions focuses on the interactions so rather than a swim lane that's collapse down it's just a lifeline the lifeline is a timeline of events relative to some element in this case we have life lines for all the components then the arrows between them represent interactions they represent messages that are passed between those components they also show this is sometimes called an activation the technical term in UML is an execution specification that shows the events that result from receiving a message and then you can ever apply back from the message these start off these ones out on this side are called found messages you can actually have lost messages on the other side there's kind of a funny name but they're actually just the external triggers that come in through those interfaces that I hadn't shown that it's shown is unconnected on the previous diagram so if you go through this you can see that you get a trigger in that says search products the user wants to search products the online shopping component goes to the search engine guess what I didn't put that connection on the diagram so we've now if you go back you can notice I didn't have that connection so we've just discovered that I'm missing a connection between the online shopping component in the search engine so technically and my tool can come up and say there is no interface between the online shopping component in the search engine so you're going to have to create one so that's how doing this modeling provides you with the ability to find problems in your system and this isn't just PowerPoint it's actually in the tool says pops up and says there really isn't an interface there I can put it on the diagram but what I really should be doing is saying create me an interface and put that on the interface and then I better go back to the design team and make sure I can do this oops and so we want to be able to do the search then when we select a product create the order go to order management goes to customer management customer management talks to inventory management that all works okay so the rest of this pretty much works the way we want I can run through this if I have many use cases many requirements I can run through this for each use case for each requirement scenario and validate that my design actually can meet the needs and where I can't I can go ahead and update the design in the model and I can go back to the teams or whatever my organization is to say how is this going to impact we forgot to put this interface on how is it going to inter impact you know delivering on our product so let's go down another level of detail we go inside the order of management component and now we're designing the implementation of that order management component well obviously a big part of that is going to be what's an order so we have done a class diagram here in order to describe an order to describe what an order is this is the boxes here are classes which specify a set of individually identifiable objects in a domain so the object is an instance of a class as the terminology so we heard an instance of the object is a specific thing so a product that product class describes the whole categorization the classification of products an individual product is an object and a product object is an instance like a member of the category of products each class can have a set of attributes this defines the information that needs to be maintained about the objects that are instances of that class a product has a description and unit price an order is then made up of ordered line items which have a product reference a product have a quantity and in the mount when I say like order has a set of Laura order line items you notice there are lines between these the lines between these things are relationships or associations between the classes they provide the ability to link classes up so an order is linked to a customer a customer can have many orders that's in UML called multiplicity which is just a fancy way of saying it's the balance on the number of things so where there's a 1 it means you can have 1 every order has 1 customer but a customer when you see a star can have multiple orders I mean zero or more and I can specify bound you can see here like a shipping addresses that 0.1 means you can have either 0 or 1 and I could say you could have 0 2 3 etc you know customer you may not know the shipping address at first and have to ask the shipping address along the way and then you fill that in they don't have more than one ship address in this model right so that provides an overall model of the information I need to maintain about an order in its relationship the customers and credit cards etc now you notice that order has a thick has these two bars on the side if you look closely it's a little bit different than like water line item that's not a mistake that means that I'm modeling that is what's called an active class it has a behavior and order objects have a life cycle and I can represent that life cycle using a state machine so a state machine is a way to specify event-driven behavior that goes through a number of stages and each state represents a stage in the life cycle of that object the order object starts out in waiting for checkout and then moves when you checkout it moves to establishing a customer and for our fine payment when you submit a charge it moves to the submitting charge state from that state either the charges denied in which case you notify the customer and they can resubmit the charge or the charge is approved and the order is shipped the lines between these things so it starts I should have said that black dot you know the start of things tend to be black dots so it's similar to an activity that big black dot is the initial state and the transition between states is triggered by events that are signal there's actually a number of ways to do this operation signals but usually the reason you do it with this kind of a state machine is you've got some sort of triggers something that comes in those messages that come in and say the user says they want to check out and that triggers the next step in this process and the actual behaviors that happen are these entry behaviors so when you enter the state it carries out that behavior which can then be further specified itself using an activity diagram or using another behavioral model down in another level of detail or it can be a specification for something that's going to be implemented in software all right so that carries us through sort of a an overview of how you can use UML to run through this design process for this system assuming we've run through this and now we're actually packaging this up physically to be delivered we want to talk about this overall physical structure of the model this is a deployment diagram which shows the physical modularization the concept here is that you have these logical components in your system but you're going to package those up in physical pieces in UML the generic term is artifact this is something you know for software physical meaning it's like a file as opposed to something in your UML tool or a piece of software in it can though as you'll see in a system L artifacts could actually be much more physical than software anybody how many people here are like Java programmers or dealt with Java that's the other example I didn't use that here but if you're a Java program that's like a jar file it's a way to package things up what is packaged in them is these manifest what's called manifestation relationships I didn't come up with these terms folks I just say them but so what we have here is that the web client module has in it it manifests those three components the search engine online shopping and authentication the ordering services module has order management and customer management etc we then can have nodes which are computational resources on which the artifacts can be deployed and those nodes can communicate with each other so my design here is that I actually have two servers two nodes which are expected to be servers actual physical computers the web server hosts the web client module and the ordering services and warehouse services modules are deployed on the backend server so that carries through slice all the way through from requirements through architectural design and validation to detailed design to going all the way down to your physical deployment modeling any questions any further questions all right so that's our high-level journey through UML but we've just started so now we're gonna go to the systems modeling language sysml we'll also have an example here this example peel card is a little bit more detailed but you'll see it builds on a lot of what we just saw in UML and adds some additional capabilities so I won't go into detail about the stuff I will show example the example will include things like state machines and you'll see variants of this composite structure but I'll focus on the things that sysml adds to it well where did system all come from the version 1.0 from D actually had an introduction much of this has disappeared in the later versions but if you go back to version 1.0 it points out that the origins of system L go back to a decision made by the encode Z with system engineering and cosy model driven system International Council on system engineering inkosi which is the professional body for system engineers to customize the unified modeling language so this didn't come out of the UML community as such this actually came out of the system engineering community and was the beginning of a long relationship between inkosi and OMG that continues to this day with work on system elf so the system engineers we're looking for their unified notation in the sense that the three amigos had unified object oriented development notations the system engineers were looking for ways to unify their notations which they already had a lot of at the time in 2001 so the goal here is to support the wide range of activities that system engineers do for complex systems specification analysis design verification validation how many people are involved in system engineering you might have asked that before but you know you'll be familiar with that whole life system engineering lifecycle sysml covers that whole thing for systems that include software hardware information processes anything right anything can be a system we we aren't just talking about software systems or hardware systems we're talking about humans in the loop we're talking about cyber physical cyber physical human etc business systems personnel systems they are all conceived as being possible to include in a system l model what continues with from system l1o to the current version which is system l15 is that system L is based on UML it reuses a subset of UML defines UML force SML as the subset of UML and then extends that so it provides a extended subset of UML focused on the needs of system engineers well how do you do that the extensions are provided through the UML profiling mechanism remember that I mentioned that a profile is a tailoring of UML as a language to focus on the needs of a specific community or domain the way that's done technically is you have these specific annotations called stereotypes and you can see an example here these are examples of sysml diagrams these are obviously compressed thumbnails but you can see on the ear the little things that are in demos actually in UML they're called Ghia mozdok technically really key maze but the double angle brackets those annotations are stereo type annotations they're actually you can model a profile and it's stereotypes so sysml actually has a model of the system l profile which is a UML model of how UML is specialized in order to provide the system l specific extensions will point those out as we go along you can see here requirements block those are big in system Elva annotate the way UML is used for additional capabilities for system engineering cinema also defines a few new or modified versions of UML diagrams and that goes beyond what a lot of profiles do but it was considered important for system L so if you look here you can see BDD and IBD and PA are those are new kinds of diagrams that will talk about BDD as a block definition diagram IV DS an internal block diagram so there are and parametric those are specializations and extensions of UML diagrams not just the basic model elements but of how you use the diagramming itself requirements diagram is pretty much a specialized class diagram then you've got activity bottles all right so I'm going to run through an example here this example is actually from a practical guide to sysml the system modeling language by Freedent all Morton's freethought Morin Steiner used by permission I want to thank Sandy Frieden fall for pointing me to this and allowing me to use it this material it's a very good example that we're gonna go through sandy is and is still sir mr. sysml he was a force behind getting the first system l Don he's co-chair with me on the submission group for the system L version two so the example we're going to talk about is an example of putting together an automobile and we're going to start with the idea of what are the requirements for this automobile now remember I talked about under UML doing functional requirements using use cases you can still do that you can still have functional requirements in your system model but there's a lot more to requirements than just the functional requirements and system engineers often come to the task with a large set of contractual or other textual requirements so system all provides a way to organize those textural requirements that way you can put them into the model and once they're in the model you'll see when we get to and you can trace your design back to those requirements statements so here we've got the basic idea of a requirement and it uses that requirement stereotype it specifies a capability or condition that must be or should be satisfied the diagram shows how a requirement can contain sub requirements so the automobile specification that is made up of requirements for passenger and baggage load vehicle performance riding comfort and the other things that are listed on there now this doesn't have the detail of all those requirements but each one of those requirements gets an ID and a textual description so that provides a basic way to take like a large requirement document with sets of requirements put the IDS for those and the text for those and organize them in the model so you can have your traceability links within the model and that doesn't give you much more in terms of formality but once you've done that that's a starting point and you can move to actually then using more formal models like a use case model so here's a use case model for the vehicle itself same kind of model that we talked about we're just now describing the requirements on a physical vehicle rather than an online shopping software system where we have a vehicle occupant and this the the notation here is the passenger and Driver are kinds of vehicle occupants and any vehicle occupant needs to be able to enter the vehicle and exit the vehicle and patrol vehicle accessory a driver needs to drive the vehicle and by the way if there is a sliding event that should automatically trigger the anti-lock braking so you can see the use of the extent relationship there again this is no different than UML regular UML use cases we're just now applying it to a vehicle remember we talked about doing a realization of or a process that realizes the use case I showed earlier an activity model doing that you can also use a sequence diagram I use the sequence diagram in the UML example later on in the architectural phase it's pretty common to also use sequence diagrams as the behavioral realization of a use case that's particularly common in sysml where you have a lot of interaction going on with the physical system and in fact what this shows is the ability to break down that interaction model remember it's got the life lines on the sequence diagram we have a driver and vehicle we're talking about the interaction at this point between the driver actor and the actual vehicle well there's a lot that goes on those boxes there are called interaction uses and you can see it expands on the right to a lower-level sequence diagram so in order to turn on the vehicle the driver turns the ignition on and the vehicle goes back to the driver and says I'm on now that one's not very detailed but it fit on the chart other ones of them will have more involved behavior and that behavior can be allocated out to a more detailed activity model now you notice here this is an activity model with swim lanes so we're using both a sequence diagram and an activity diagram in this case not only do we have control flows but we also have object flows so basically data flows but in your model called object flows but data flows between the various behaviors a nice specialization the system L is done you know they have a differentiation but you control flows and object flows actually in UML activity diagrams both kinds of flows whether you're just doing control or you're actually moving some data around or done with just arrows and sysml they said that's confusing so the control flows if you notice over here the dotted lines or control flows this says the driver starts at the same time pushes the accelerator and changes the gear selection right so there's no sequencing between those two that's the fork then we have an accelerator command that goes from the accelerator to provide power that's a object-- flow and we've got a gear so that goes to provide power which then provides torque that goes out of this so that's a small specification of the behavior that is used within controlling neutral forward or reverse power so that's how some of these things fit together in assists in all context now state machine system engineers love state machines because they're dealing with physical systems physical systems you can't always organize a nice sequential process they're almost always reactive to events so you need to deal with that in terms of both your physical hardware and software systems you need to deal with events and state machines are a great way to organize that so you can use the state machine to define the operational states of a block we'll see that system engineers would like to call everything blocks so what in UML is called the class and system is called a block so we've got a vehicle we just looked at driving the vehicle well what are the state's the vehicle is off you turn the ignition on start the vehicle the vehicle turns on well you notice here this is a little more complicated in the state machine I showed before we have a composite state which has sub states between it so a vehicle could be on or off when it's on then while it's on it can be either in neutral moving forward or moving in Reverse and you again have the transitions between those things but you notice we have more ways to add behavior to this in addition to an entry action we have do they're called do activity behaviors which is kind of strange name but that's historical so the du says all right when you enter vehicle on the entry says check status once you're done checking status start providing power that continues while the vehicle is on it provides power when the vehicle is turned to off the exit behavior says accessories should be turned off when the vehicle is turned off there's also I didn't point this out but you can see ignition on slash that start vehicle as a behavior that happens during that transition that's a transition behavior and you can also have guards so if you're in neutral again this is to be what you'd expect if you're neutral and you select to move forward you actually only move forward if your speed is greater than or equal to zero right so if you're have reverse selected then you're actually moving in Reverse if your speed is less than zero if you're moving backwards what that does is prevent the model from a situation where you're in Reverse and the model says your speed is moving forward you that is not supposed to be able to happen all right let's look now at the decomposition of the vehicle we thought that and software terms a decomposition into components the structural decomposition of things in system L is also extremely important in fact it's so important that they have specialized UML diagrams specifically for that purpose this is a B DB which you can't quite see it's cut off on the top it's a block definition diagram you see the stereo tape block a block is a modular unit of system description this is a stereo type of class so in UML what's called the class system engineers they'd like they really like block diagrams right these don't look like block diagrams but to a system engineer really is a block diagram and they talk about these pieces they don't think of them in classes and the software sense that's really that term of class came from object-oriented development is historical in UML the really more generic to think of it as a block so that's the way they think of it and then blocks may be composed of other blocks 'iz blocks those that black diamond there that is actually a standard UML notation for composition this shows that a grammatically rather than showing what I showed before which is showing the decomposition in terms of a layout of components this shows in more of a hierarchical tree chart kind of way that the vehicle is composed of these other blocks but it's actually using a standard UML notation for that the block can also generalize other blocks that is also a standard UML notation for generalization so what this says is that a vehicle has a power that powertrain includes an engine the engine can be either a four-cylinder engine or a six-cylinder engine that's all hardware and you notice the additional stereo types these are standard additional system l stereo types that can be applied the vehicle has a bunch of Hardware pieces but it also has software blocks can represent both hardware and software and other kinds of components and you can allocate between them so you can see here that the vehicle controller software is allocated to the vehicle processor so the software allocation is included on this as well as the hardware and notice there are multiple stereotypes is allowable to apply multiple stereotypes so each of these stereotypes is a block and it is further stereotyped whether it is the overall system of interest hardware software etc this is the internal block diagram so this is taking those component pieces and showing how they are connected together this you can sort of see is a specialization of the composite structure diagram kind of notation I showed earlier you can see that the basic idea of components and ports and connectors but what you have here is an addition and sysml of the idea that ports can have flow properties so that basic idea there was a question about ports and interfaces and whatnot the system engineers really didn't like that idea of having provided requires interfaces blah blah blah they wanted to define think of defining behaviors directly on ports now really in the underlying UML model what they're doing is defining the type which is a class and that port has that type really that's what's happening but the way they're thinking about it is that's a port it has flow properties they're stuff that flows in and out on that that's the way they wanted to think about it so they have specialized the notation so they can think about it that way and underneath the tools will map it to the way it has to be mapped so the flow properties specify the kinds of items that might flow between blogs I remember this is a hardware system in this example we're not necessarily talking about data we're talking about real stuff that could flow fuel or more abstractly torque right we're talking about physical properties can flow between these things the arrows indicate how they're flowing you can see that there's stuff flowing into the let's say the engine you can see air is flowing into the engine the engine then connects to the transmission the ones with the two arrow heads that means it's going both directions these little arrows here with the solid arrow heads on them are called item flows that specify the items that actually flow between the blocks now for simplicity some of these you know it doesn't have the detail showed shown it does not show the detail of the flow between the transmission and the differential but you could tell by looking at the specification of the flow properties on the port's where we actually are showing it here is what when is flowing in and out of the vehicle as a whole this shows that you've got torque flowing out of the right rear and the left rear tires that will connect to the road that's the points where the vehicle connects to the road on the other side you can see the air flowing into the vehicle and the fuel flowing into the vehicle from the bottom the chassis has the fuel tank so that that fuel isn't flowing and hopefully while the thing is moving that's the fuel cap the fuel port another specialization is a parametric diagram now that what I showed so far is basically just a way to use the basic UML concepts we saw earlier specifying structures specifying behavior and tailoring that for the way a system engineer wants to think and adding some additional concepts like being able to deal with flows that go in and out of blocks representing physical things as engineer wants to go beyond that a lot of what a system engineer does is an analysis of the system the reason they model is to understand their design of something to be built and do analyses on it and often doing trade off and optimization studies in order to do that they need to get a lot of technical

Channel: Object Management Group

Views: 14,857

Rating: 4.9417477 out of 5

Keywords: UML, • Unified Modeling Language, SysML, Systems Modeling Language, Object Management Group, Modeling standards, Modeling languages, OMG, Standardization

Id: vAHHdnIV8rU

Length: 45min 57sec (2757 seconds)

Published: Fri Nov 16 2018