Ai Assisteed MBSE | Videos

language: EN

                  WEBVTT
This is cool because I can watch and see when everybody's ready, instead of asking everybody
to raise their hand when they're ready.
Yeah, I only have it open once, so I'm going to leave it with two, because – all right,
So everybody is now – I can see – got their new project created.
So here's what we're going to do first.
We're going to make a new diagram, and it's going to be a package diagram, so SysML package
diagram, and I'm going to call this top level project – or actually, I'm going
to call it electron microscope.
And then on that electron microscope diagram, I'm going to make a package called conceptual
model, I'm going to make one called logical model, and I'm going to make one called physical
model.
Now I get to go –
All right, I apologize, were you creating elements?
So let me go back and kind of reconstruct what I did.
So the first thing I did here is I created a new diagram, and when I created the new
diagram, I made it a SysML package diagram, and then I named it electron microscope.
Then I put three packages on there.
So for Daniel and Mark, what I'm going to do next is I'm going to go in the containment
industry, underneath conceptual model, and create a package called domain model.
But I want to let Elena catch up here.
Sure, I don't understand – I'm sorry, this is definitely really new to me.
I don't understand how you did the three packages you said within it.
Okay, so let me – so I think if I double click on your screen –
So I'm just adding – okay, I got it now.
I got it.
It's just where my package is here, and then maybe –
So Maria, if I want to just go look at Elena's screen, what do I click on here?
Is it –
So there are two ways you can do it.
I usually – pretty much you can just slide on the sheet, probably in the CML,
but I will just click from the original, like the main website that we have, the desktop,
and then I'm going to double click on Elena's screen.
So let's go back to the desktop, soft light, cleaning room, and then –                

on 2024-12-16

language: EN

                  WEBVTT
So now I'm going to do what I just suggested a minute ago, which is I'm going to create
a package inside conceptual model called domain model.
So that's create element package, call it domain model.
And now I'm going to create a BDD inside there, and I'm going to leave it called
domain model.
And then I'm going to go to my slides and what I have is an electron gun, an imaging
system, a vacuum system, detector, all that, right?
So how do I get back to my, how do I get back to my, so I don't know if you all
know how to use the sticky button in Cameo, but I'll show you how to do that.
Let's see, Elena, are you caught up now or not yet?
I think so.
I'm good to go.
Okay.
So if you've never used the sticky button in Cameo, it is this little icon here.
And you use it when you have to create a whole bunch of elements that are all the
same type.
So I think I need to create like seven or eight blocks here.
So I'm going to click the sticky button, click on block, and go one, two, three,
four, five, six, seven, eight.
I don't know if that's exactly the right number, but then I'm going to turn
the sticky button off and I'm going to start naming these.
I'm going to show you a little driving trick with Cameo, and that is this little
make preferred size button here.
Yeah, to save you just hit this little floppy disk icon.
But I think we'll be done with this diagram in five minutes.
So what we're doing now is we're just copying the BDD out of my PowerPoint slides.
And we're going to use composition, directed composition, to map all these
together, connect them all together.
I can use the sticky button for that too, so I can make all my directed
composition relationships that way.
And then I'm going to name all these.
So electronic imaging system, vacuum system.
Then I made one block too many, so I'm going to delete my extra one.
And then I'm going to use this quick layout button, lay it out like that.
And let me just check how everybody's doing.
Looks like we're doing good.
And the last thing we'll do before lunch.
Is we're going to create a glossary.
And we do that by right clicking on domain model.
Go to create diagram.
Under other diagrams, there's something called the glossary table.
And what we do with this glossary table.
Is we're just going to take all of these blocks.
Drag them onto the glossary table.
And now we can put in the glossary descriptions.
So that's actually our first lab.
And we finished it a minute before lunchtime.
So I think we're good.
Just drag them over from the containment tree into the empty space on the diagram.
Oh, just into here.
And then just select the elements to table.
I think you're doing things and I'm staring at my computer and I'm not looking at what you're doing.
No problem.
Just need a little heads up that you're about to do something and then I can stop looking at mine and then look at what you're doing.
We will calibrate to this as we go on.
Thank you so much.
My goal was to get us through this by lunchtime.
So it is now lunchtime.
Right, right to the minute, Maria.
And so we'll see you back here at one thirty.
Thank you.
Yep.
I think we're good, Maria.
It ain't broke.
Don't fix it.
No, I think we are.
We're off and running and actually got through the first lab before lunch.
Right.
All right.
See you in an hour.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Hello.
Welcome back.
I'm migrating to a new target data center for my connection.
All right.
Is that something that's in progress or are you done doing that?
It's doing it, but I don't think it's going to slow us down.
It's been about a minute and a half for the connects.
It's not much faster.
I heard something about that.
Yeah.
A pop-up came up and said that I could get a better connection if I migrated.
I put yes about a minute and a half ago.
I'm off cancel.
I'm fine, I'll just use that.
Yeah.
Thanks.
Okay.
So, Elena and Daniel, are you guys back?
It's a yes from Daniel.
Okay.
Well, while we are waiting, let me once again ask for some feedback.
How's it going?
How's everybody doing?
Are we still on a good pace?
Too fast?
Too slow?
Too deep?
Too shallow?
Where are we at?
I'm not sure what you said, Daniel.
Was it all good?
Yeah.
Okay.
Your voice kind of fades out a little bit when you're talking, but I'm going
to take that as an all good.
Mark, you good?
Yeah.
I'm fine.
Although I ran out of coffee, so I'm a bit of a pickle over here, but otherwise
one is good.
Yeah.
If we need to pause for people, that's great.
I've had my moments where I get behind, so I'm fine.
Yeah.
Okay.
I'm trying to keep everybody synced up the best I can.
Yeah.
My impression is that the two of you from Raytheon probably have more hands-on
cameo experience than Elena does, so I'm trying to go at a pace where she can
keep up and you guys don't get frustrated waiting.
So if I'm not doing a good job at that, let me know.
But hopefully it goes okay.
I've been teaching for quite a large number of years, so I feel like I know how to
handle it, but if I need to get feedback from you, don't hesitate.
It's also nice to see what they're struggling with, because other people are
having the same problem, so I'm like, oh yeah, I do have to explain what this
little weird-looking bundle button up here means, and they don't just know it,
so it's good to see what the challenges are.
Yeah, cameo is a piece of software that has like 18 million features in it,
and I certainly don't know all of them.
I know the ones that I use all the time, which is quite a few of them,
but you know, it's not all of them, right?
Yeah, also there's a lot of user interface inconsistencies in cameo.
You can sort of see that parts of it were developed by different teams at different
periods of time, because there'll be sections of it that have sort of the same
user interface idiosyncrasies to them.
And they clearly didn't write any use cases when they built cameo.
They didn't use like EML and use cases to design it, because one of the
use cases is that features that are really hard to read when you try and document
how they work in use cases, they read completely ridiculous.
And so my favorite one is the standard and expert mode toggle, where it's in
expert mode when it says standard, and it's in standard mode when it says expert.
And the documentation says click on this button that's not there, or menu item that's
not there, because you're not in super expert mode.
Yeah, I taught a live in-person class last week, and there was one guy in the
class who kept thinking he's in expert mode because it says expert on a
screen. Why would anyone ever think that? I don't know, but you know.
It's crazy.
Yeah, I taught with Sparks for many, many years before switching over to cameo.
And for UML, Sparks pretty much I think dominated the industry, but with
SysML cameo kind of took over.
Yeah, which was strange. It fell apart.
I'm sorry, it was free, but we probably spent more money, you know, fixing
things.
Debugging it, yeah.
Elena, are you back yet?
Elena is not back, but we're seven minutes over time, so.
Nothing you can say.
Okay, so I'm going to go back to PowerPoint for a few minutes, and then
we'll do some more cameo modeling in a little bit.
I'm just going to put a note in the chat for Elena to say please let us
know when you're back.
All right, so, by the way, these domain objects didn't come out of thin
air, they came out of me asking ChatGPT, alias Dr. Nano, what the
domain objects were, and I can kind of show you what his response looked
like.
So, basically, when, this was very, very early in my chat session
with ChatGPT, and by the way, I exported it to Word somewhere about
when I was writing this chapter, and my conversation was over 300 pages
long, but it kind of started here, which as I just said, gave me a set
of domain objects for scanning electron microscope and their
definitions, and it kind of gave me those like that, it gave me the
rest of them, and it kind of looked like this, and then I sort of
had a detour into asking it to write some use cases, and we cover
the use cases in the use case chapter, not here, but this was pretty
early in the book project when I was still getting to know Tim, my
co-author, and we were kind of on a Zoom call with Tim, or maybe
it was email, but we were talking about how basically we were
switching back and forth between doing the domain model and some
different views of the system, and so one thing I had it do was
write a couple of use case narratives and look at the text of
those, and Tim said to me, oh, you're following the zigzag
pattern, and I said, zigzag pattern, what's that, and it turned
out that Tim had written a book on his process, which is called
SysMod, and he had actually documented this going back and
forth between the requirements and the architecture as a zigzag
sort of thing, and I had just done the zigzag pattern kind of
intuitively because that's always how I work, but then he gave it
a zigzag pattern, and so we decided to put that in the book,
and I thought it was a very insightful thing that he had done
is to recognize that you zigzag back and forth in between
different views of a system as you develop it, and it really
helps you discover things. He was using it to discover
requirements, which we'll get to in the next slide deck, but
I used it in particular to get some information out of the
use cases and get some information out of subsystem
decompositions, and in a sense, we're kind of cheating
a little bit because we really haven't done a subsystem
architecture yet, but even though we hadn't done the
subsystem architecture, we kind of cheat and have AI take
a guess at the subsystem architecture even though it
wasn't final, and that helped to discover some more
domain objects. So when we had Dr. Nanow start writing
use cases, he came up with some interesting nouns like
he had pre-processing tasks, image enhancement techniques,
ROI, which is region of instruments, operator settings,
instrument settings, and so we started adding some of
those to the domain model, and one of the nice things
about how AI works is you can almost always ask it
for more detail on anything that you're doing, and it
has kind of a habit of presenting things to you,
maybe 10 items at a time or maybe 20 items at a
time, but it'll tend to not give you 50 items at a
time or 200 items at a time because people don't work
that way and they can't handle that much complexity or
that much detail all at once. So I asked it to define
things like what's a pre-processing task and what's
an image enhancement technique, and it started giving
me more detail, and then this was sort of an
interesting prompt, which was I kind of asked it to
tell me the subsystems of the electron microscope
and tell me some of their parts, and if you look
at the domain objects column here, it came up
with things like a pumping system and the sample
chamber and the secondary electron detector and the
backscattered electron detector, and all of these
are nouns that are in the problem domain, and it's
kind of subjective which ones you want to add to
the domain model, but the rule is kind of things
that the user of the system would sort of
intuitively understand. So if you're using an
electron microscope, you probably have some idea
that there's an electron detector that looks at
the electrons that are bounced off of the
sample. While I wasn't and I'm not a domain
expert on electron microscopes, I had in a past
lifetime worked on a system called an electron
beam lithography system, which is used for
semiconductor manufacturing, and hardware wise
what's in an electron microscope and what's in
an E beam lithography system are pretty similar
to each other, completely different use cases,
but hardware wise there's still what's called
a sample stage, which is where you put the
sample that you're examining under the
microscope or where you put a silicon wafer
if you're doing VLSI kind of lithography
things. And that sample stage is essentially
a platform that can move in two dimensions,
X and Y. I guess in a microscope it can also
move in Z, but it's you kind of put your
sample on this stage and the stage moves around
back and forth, and then the electron beam
kind of comes down this column and it impinges
on the sample. And so I used a little bit of
my own domain knowledge and a lot of my
experience in building domain models for
hundreds of different projects to kind of
break this down a little further.
So Elena, are you back yet? No. Okay.
Well, I think Elena's going to get behind
a little bit because we need to sort of
keep moving at this point. So what
your job is going to be next is to go
back into Cameo and we're going to basically
add to the diagram we were building
and build it into parts, kind of a
hardware part, which I put on the left,
and a software part that
sits over on the right side of the diagram.
So I'm going to actually put my
slides on my second monitor here so I
don't have to switch back and forth all
the time, my second monitor being
lower resolution than my first monitor.
And, whoops, where did it go?
Nope, that's not it.
Oh, bear with me for a second while I find
where my slides went.
I think it went here.
So what you can do is you can start
Cameo and start expanding
your domain model, and I will
do the same here in a minute.
I've got a question. So, I mean, it doesn't
really look like it lines up one-to-one with what we were creating
before. How does that plan out?
So you can either make a new diagram or you can just
modify the diagram that
you had started. And we'll probably have to regenerate the glossary
at the end of it. But I think there's probably enough
in common with it that you can
just modify the diagram that you've had.
If I can find my DAW desktop again.
I may have to open it up again.
What?                

on 2024-12-16

language: EN

                  WEBVTT
All right, looks like we're doing good.
And the last thing we'll do before lunch is we're going to create a glossary.
And we do that by right-clicking on domain model, go to create diagram, and under other
diagrams there's something called a glossary table.
And what we do with this glossary table is we're just going to take all of these
blocks and drag them onto the glossary table.
And now we can put in the glossary descriptions.
So that's actually our first lab and we finished it a minute before lunchtime.
So I think we're good.
I'm sorry, I'm attempting to drag onto the glossary.
Am I missing something?
Yep, just drag them over from the containment tree into the empty space on the diagram.
Oh, just into here.
And then just add the selected elements to the table.
I think it's just, I think you're doing things and I'm staring at my computer and I'm not looking at what you're doing.
No problem.
We just need a little heads up that you're about to do something and then I can stop looking at mine and then look at what you're doing.
We will calibrate to this as we go on.
Cool.
Thank you so much.
My goal was to get us through this by lunchtime.
So it is now lunchtime.
Right to the minute, Maria.
And so we'll see you back here at 1.30.
Thank you.
See you soon.
Yep.
I think we're good, Maria.
It ain't broke.
Don't fix it.
That's true.
Okay, so I'll see you in an hour unless there's anything else you would like to discuss right now.
No, I think we are, we're off and running and actually got through the first lab before lunch, which is great.
So, all right, see you in an hour.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
It is a garage. They can go right into that garage. They know where it came from and where it went.
And for some reason they don't want to comment on saying what it is.
Our military notes and our president notes.
And for some reason they want to keep people in suspense.
I can't imagine it's the enemy because it was the enemy that blasted.
Even if they were late, they blasted.
Something strange is going on.
And for some reason they don't want to tell the people in this shit because the people are really...
I mean, it happened to me over at Bitmix.
They're very close to Bitmix.
I think maybe I won't spend a weekend at Bitmix.
I decided to cancel my trip.
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
Hello.
Hello.
Welcome back.
All right.
I'm migrating to a new target data center for my connection to the DAW desktop.
All right.
Is that something that's in progress, or are you done doing that?
It's doing it, but I don't think it's going to slow us down, but it's been about a minute and a half for it to connect.
That's not much faster.
Okay.
I heard something about the desktop.
Oh, yeah.
A pop-up came up and said that I could get a better connection if I migrated.
And I clicked yes, and that was a minute and a half ago.
I see.
So you get the up of it.
Interesting.
Oh, I'll cancel.
I'm fine.
Oops.
Who's that?
You know, the thing with time, you know, it's tricky.
It's slow in general sometimes.
So I'm not really sure why you have this window pop, where you just get to a faster speed, I guess.
But if everything works earlier, then let's keep it as a...
Yeah.
Thanks.
So Elena and Daniel, are you guys back?
That's a yes from Daniel.
Okay.
Well, while we are waiting, let me once again ask for some feedback.
How's everybody doing?
Are we still on a good pace?
Too fast?
Too slow?
Too deep?
Too shallow?
Where are we at?
Not sure what you said, Daniel.
Was it all good?
Yeah.
Okay.
Your voice kind of fades out a little bit when you're talking.
But I'm going to take that as an all good.
Mark, you good?
Yeah, I'm fine.
Oh boy, I ran out of coffee, so I'm a bit of a pickle over here.
But otherwise, lunch is good.
Yeah.
If we need to pause for people, that's great.
And I've got my moments where I get behind, so yeah, no, I'm fine.
Okay.
I'm trying to keep everybody synced up the best I can.
Yeah.
My impression is that the two of you from Raytheon probably have more
hands-on cameo experience than Elena does, so I'm trying to go at a
pace where she can keep up and you guys don't get, you know,
frustrated waiting.
So if I'm not doing a good job at that, let me know.
But hopefully it goes okay.
I've been teaching for quite a large number of years.
So I feel like I know how to handle it.
But if I need to get feedback from you, don't hesitate.
And it's also nice to see what they're struggling with.
And then because other people are having the same problem, so I'm like,
oh, yeah, I do have to explain what this little weird-looking
barcode button up here means.
They don't just know it.
So good to see what the challenges are.
Yeah, cameo is a piece of software that has like 18 million
features in it.
And I certainly don't know all of them.
I know the ones that I use all the time, which is quite a few of them,
but, you know, it's not all of them, right?
I'd like to mention early on, there's a 3,000-page manual that's pretty
incomplete, so don't expect to like immediately understand and know it.
Yeah, also there's a lot of user interface inconsistencies in cameo.
You can sort of see that parts of it were developed by different teams at
different periods of time, because there'll be sections of it that have
sort of the same user interface idiosyncrasies to them.
And they clearly didn't write any use cases when they built cameo.
They didn't use like EML and use cases to design it.
Because one of the things that happens if you actually write narrative use cases
is that features that are really hard to read when you try and document how
they work in use cases, they read completely ridiculous.
And so my favorite one is the standard and expert mode toggle, where it's
in expert mode when it says standard and it's in standard mode when it says
expert.
And the documentation says click on this button that's not there or menu item
that's not there because you're not in super expert mode.
Yeah.
So, yeah, I taught a live in-person class last week, and, you know,
there was one guy in the class who kept thinking he's in expert mode
because it says expert on a screen.
You know, why would anyone ever think that?
I don't know, but, you know, it's like.
It's crazy.
We began around 2001.
I was going to start up a week.
We were using the beta version of the software.
It would crash about every hour.
So, yeah.
Yeah, I taught with Sparks for many, many years before switching over to
cameo.
And for UML, Sparks pretty much, I think, dominated the industry, but with
SysML, cameo kind of took over.
Yeah, which is strange.
It fell apart.
It was free.
You know, but we probably spent more money, you know, fixing things.
Debugging it, yeah.
Elena, are you back yet?
Elena is not back, but we're seven minutes over time, so.
Okay.
So I'm going to go back to PowerPoint for a few minutes.
And then we'll do some more cameo modeling in a little bit.
I'm just going to put a note in the chat.
For Elena to say, please let us know when you're back.
All right.
So.
So, by the way, these domain objects didn't come out of thin air.
They came out of me asking chat CPT.
Alias, Dr.
Nano.
What the domain objects were.
And I can kind of show you what his response looked like.
So, basically.
When.
This was very.
Very early in my chat session with chat GPT.
And by the way, I exported it to.
To word somewhere about when I was writing this chapter.
And my conversation was over 300 pages long.
But it kind of started here.
Which is, I just said, give me a set of domain objects for scanning electron microscope and their definitions.
And it kind of gave me those like that.
It gave me the rest of them.
And it kind of looked like this.
And then.
I sort of had a detour into.
Asking it to write some use cases and.
We cover the use cases in the use case chapter, not here.
But this was.
Pretty early in the book project when I was still getting to know.
Tim, my co-author, and I was kind of on a zoom call with Tim and or maybe it was email.
But we were talking about how basically we were switching back and forth.
Between doing the domain model and some different views of the system.
And so one thing I had to do was write a couple of use case narratives and look at the text of those.
And Tim said to me, oh, you're following the zigzag pattern.
And I said, zigzag pattern, what's that?
And it turned out that Tim had written a book on his process, which is called SysMod.
And he had actually documented this going back and forth between the requirements and the architecture as a zigzag sort of thing.
And I had just done the zigzag pattern.
Kind of intuitively, because that's always how I work.
But then he gave it a name. He gave it a name of zigzag pattern.
And so we decided to put that in the book.
And.
I thought it was a very insightful thing that he had done is to recognize that you zigzag back and forth in between different views of a system as you develop it.
And it really helps you discover things. He was using it to discover requirements, which we'll get to in the next slide deck.
But I used it in particular to get some information out of the use cases and get some information out of subsystem decompositions.
And in a sense, we're kind of cheating a little bit, because we really haven't done a subsystem architecture yet.
But even though we hadn't done the subsystem architecture, we kind of cheat and have AI take a guess at the subsystem architecture, even though it wasn't final.
And that helped to discover some more domain objects.
So when we had Dr.
Nano start writing use cases, he came up with some interesting nouns like he had.
Pre processing tasks, image enhancement techniques, ROI, which is region of instruments, operator settings, instrument settings.
And so we started adding some of those to the, to the domain model.
And one of the nice things about how AI works is you can almost always ask it for more detail on anything that you're doing.
And it has a kind of a habit of presenting things to you, maybe 10 items at a time or maybe 20 items at a time.
But it'll tend to not give you 50 items at a time or 200 items at a time, because people don't work that way and they can't handle that much complexity or that much detail all at once.
So I asked it to define things like what's a pre processing task and what's an image enhancement technique.
And it started giving me more detail.
And then this was sort of an interesting prompt, which was, I kind of asked it to tell me
the, tell me the subsystems of the electron microscope and tell me some of their parts.
And if you look at the domain objects column here, it came up with things like a pumping system and the sample chamber and the secondary electron detector and the backscattered electron detector.
And all of these are nouns that are in the problem domain.
And it's kind of subjective which ones you want to add to the domain model.
But the, the rule is kind of things that the user of the system would sort of intuitively understand.
So if you're using an electron microscope, you probably have some idea that there's an electron detector that, you know, that looks at the electrons that are bounced off of the sample.
And I had, while I wasn't and I'm not a domain expert on electron microscopes, I had in a past lifetime worked on a system called an electron beam lithography system, which is used for semiconductor manufacturing.
And hardware wise, what's in an electron microscope and what's in an E beam lithography system are pretty similar to each other, completely different use cases.
But hardware wise, you know, there's still what's called a sample stage, which is where you put the sample that you're examining under the microscope or where you put a silicon wafer.
If you're doing VLSI kind of lithography things, and that sample stage is essentially a platform that can move in two dimensions X and Y.
I guess in a microscope, it can also move in Z.
But it's, you kind of put your sample on this stage and the stage moves around back and forth.
And then the electron beam kind of comes down this column, and it impinges on the sample.
And so I used a little bit of my own domain knowledge and a lot of my experience in building domain models for hundreds of different projects to kind of break this down a little further.
Okay.
And so, Elena, are you back yet?
No.
Okay.
Well, I think Elena is going to get behind a little bit because we need to sort of keep moving at this point.
So what your job is going to be next is to go back into Cameo, and we're going to basically add to the diagram we were building and build it into parts, kind of a hardware part, which I put on the left, and a software part that sits over on the right side of the diagram.
So I'm going to actually put my slides on my second monitor here so I don't have to switch back and forth all the time.
My second monitor being lower resolution than my first monitor.
And whoops.
Where did it go?
Oh, bear with me for a second while I find where my slides went.
Oh, I think it went here.
So what you can do is you can start Cameo and start expanding your domain model.
And I will do the same here in a minute.
I've got a question. So I mean, it doesn't really look like it lines up one to one with what we were creating before.
How's that playing out.
So you can either make a new diagram or you can just modify the diagram that you had started.
And we'll probably have to regenerate the glossary at the end of it.
But I think there's probably enough in common with it that you can just modify the diagram that you had.
If I can find my desktop again, I may have to open it up again.                

on 2024-12-16

language: EN

                  WEBVTT
So, let me try to share this.
I'm not sure if you know about this feature of Cameo, but you can actually click on, actually
maybe it's just in the File menu, I can just say Save As Image.
And now the question is, so here's my domain model.
Actually, I don't know if I can move my image onto your virtual machine or not.
So, I can take this file and move it to Elena's computer.
So, here's the image.
It's in this PC documents, and I guess I can put it on my desktop.
Let's see, can I just drag this to the desktop?
So, here's my domain model image.
Can you move that to Elena's computer?
Not sure I know how to do that.
Oh, I might be able to figure that out.
I think it's if I go here, I should be able to...
So, it seems to be trying to move it, but it doesn't.
Now, I need permission.
I think it's fine if Elena just works from the slides, or I can just leave my diagram
on the screen.
I can leave that there.
So, Mark, if you're done while we're waiting, you may want to go make yourself a chat GPT
license, which would mean just going into your web browser and going to OpenAI.com
and creating an account.
So, that might be something that YouTube could do when you're ready, just because Elena
already has one.
Yeah, I remembered I had an account.
I just haven't used it for a while.
Okay.
I don't see any option to create an account on OpenAI.com.
You might have to go find something that says try chat GPT.
I went to chatgpt.com.
There were some...
It looks like it's up there too.
I mean, you don't absolutely need one, but if you want to try, instead of copying
what I did, if you want to try doing some prompting yourself, then you'll need one.
I'm good.
I never raised my hand.
Did I finish way before, Mark?
Just saying.
Okay.
So, you guys are done.
And we'll wait a few minutes for Elena.
Or maybe what we can do, Elena, you can maybe finish this diagram at our next
break.
How about that?
Yep.
That works for me.
Okay.
So, then I will go back to our slides.
I'll just sort of move this back to my desktop there.
All right.
So, the slides basically continue saying essentially before you start writing
requirements or writing use cases, it's a very good idea to publish this
glossary across your project and do your best to get everybody using the
same set of nouns to describe the system, whether they're writing
requirements or use cases or anything else.
You're really just better off to get everybody on the same page with
vocabulary.
And if you want to kind of look ahead to what's coming in the logical
architecture, you can ask AI to make you a table that shows you the
attributes which in SysML are the value properties and the operations in
a table for each domain object.
And what you notice is that what AI is actually doing is it's doing object
oriented design.
It's putting the operations, which are the functions, on the domain
objects.
So, normally we're not going to do this step until we get to logical
architecture, but what you can see is that we haven't done anything
that we've called functional decomposition at this point.
But if you look at the operations column on that table, it's populated.
So, chat GPT or AI has basically identified a bunch of functions for
you without you having to go and draw activity diagrams and decompose
activities into sub activities.
And all of the things that when I asked, does your project spend a lot of
time on activity diagrams?
And you guys said, yeah, it does.
We've basically gotten to the full set of functions, not the full set,
but a pretty reasonable set of functions without doing any of that
decomposition on activity diagrams.
We haven't drawn any activity diagrams yet.
And yet we've still discovered a whole bunch of functions in the system.
So, you get to the same place with an object oriented design and you
get there a lot faster if you're using AI to help you get there.
So, this is kind of the lab that you just did.
I gave you the lab before I gave you the slide on the lab.
But essentially, let's use this slide for review.
Any questions on any of the things that you did in this lab?
All right.
So, that will bring us to our next slide deck,
which is AI Assisted Requirements.
And we've been back from lunch for an hour now,
so why don't we take a 10-minute break before we start this next module.
And we'll come back.
It's 2.30 now.
We'll come back at 2.40.
And, Elena, that will give you 10 minutes to finish up the domain model diagram.
Sounds good.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Great.
So, any questions on domain modeling before we move on to requirements?
I just want to make sure I'm going off of the right example.
And also, I feel like I created things that I didn't participate in.
Well, let's see.
Let me try and remember how to get back to opening your screen.                

on 2024-12-16

language: EN

                  WEBVTT
So, let me try to share this.
I'm not sure if you know about this feature of Cameo, but you can actually click on, actually
maybe it's just in the file menu.
I can just say save as image.
And now the question is, here's my domain model.
Actually, I don't know if I can move my image onto your virtual machine or not.
So, I can take this file and move it to Elena's computer.
So, here's the image. It's in this PC documents.
And I guess I can put it on my desktop.
Let's see, can I just drag this to the desktop?
Yeah, so here's my domain model image.
Can you move that to Elena's computer?
Not sure I know how to do that. Oh, I might be able to figure that out.
I think it's if I go here.
I should be able to.
So, it seems to be trying to move it, but it doesn't.
Whoops. Now, I need permission.
I think it's fine if Elena just works from the slides, or I can just leave my diagram on the screen.
So, Mark, if you're done while we're waiting, you may want to go make yourself a chat GPT license, which would mean just going into your web browser and going to OpenAI.com and creating an account.
So, that might be something that you two could do when you're ready.
Just because Elena already has one.
Yeah, I remembered I have an account. I just haven't used it for a while. Okay.
I don't see the option to create an account on OpenAI.com.
You might have to go find something that says try chat GPT.
I went to chatgpt.com.
There were there were some, it looks like, looks a lot of sites out there too.
You don't absolutely need one, but if you want to try, instead of copying what I did, if you want to try, you know, doing some prompting yourself, then you'll need one.
I'm good.
I never raised my hand, but I finished way before, Mark. Just saying.
Okay, so you guys are done.
And we'll wait a few minutes for Elena.
Maybe what we can do, Elena, you can maybe finish this diagram at our next break. How about that?
Yep, that works for me.
Okay, so then I will go back to our slides.
All right, so the slides basically continue saying, essentially, before you start writing requirements, or writing use cases, it's a very good idea to publish this diagram.
Across your project and do your best to get everybody using the same set of nouns to describe the system, whether they're writing requirements or use cases or anything else.
You're really just better off to get everybody on the same page.
And if you want to kind of look ahead to what's coming in the logical architecture,
you can ask A.I. to make you a table that shows you the attributes, which in SysML are the value properties and the operations in a table for each domain object.
And what you notice is that what A.I. is actually doing is it's doing object-oriented design.
It's putting the operations, which are the functions, on the domain objects.
So normally we're not going to do this step till we get to logical architecture.
But what you can see is that we haven't done anything that we've called functional decomposition at this point.
But if you look at the operations column on that table, it's populated.
So ChatGPT or A.I. has basically identified a bunch of functions for you without you having to go and draw activity diagrams and decompose activities into sub-activities.
And all of the things that when I asked, does your project spend a lot of time on activity diagrams?
And you guys said, yeah, it does.
We've basically gotten to the full set of functions, not the full set, but a pretty reasonable set of functions without doing any of that decomposition on activity diagrams.
We haven't drawn any activity diagrams yet.
And yet we've still discovered a whole bunch of functions in the system.
So you get to the same place with an object-oriented design and you get there a lot faster if you're using A.I. to help you get there.
So this is kind of the lab that you just did.
I gave you the lab before I gave you the slide on the lab.
But essentially, let's use this slide for review.
Any questions on any of the things that you did in this lab?
All right.
So that'll bring us to our next slide deck, which is A.I. assisted requirements.
And we've been back from lunch for an hour now.
So why don't we take a 10 minute break before we start this next module?
And we'll come back.
It's 2.30 now.
We'll come back at 2.40.
And Elena, that'll give you 10 minutes to finish up the domain model diagram.
All right. Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Any questions on domain modeling before we move on to requirements?
I just want to make sure I'm going off of the right example.
And also, I feel like I created things that I didn't part of today.
I don't know how I did that.
Well, let's see.
Let me try and remember how to get back to opening your screen.                

on 2024-12-16

language: EN

                  WEBVTT
It looks like everybody's either with me or close, so I'm going to go back here, and now
I'm going to make a requirements table in that package.
So that is create diagram requirements table.
Now for the scope, I'm just going to drop my requirements package on the scope.
And you see that they're here.
And now I can just type the text in.
I can type it in either on the diagram or in here, but if I go back to my
requirements diagram, that should be populated.
So there is a way where you can go directly from chat GPT and paste into either Word or Excel
into a CSV, and there is a capability for CSV import or copy and paste.
But I'm probably going to leave that to your own devices unless you want me to poke at it a little more.
I will show you one other thing about the requirements numbering.
So again, to get back into that numbering dialog, I click these three little dots.
Couple things you should know about this numbering.
One is it's really easy to get gaps in your numbering sequence.
So I can, for example, increase that number or decrease it.
But in practice, what often happens is that, you know, you add some, you delete some, and they're not numbered the way you want, and you get gaps in the numbering.
So there's two important things to know about the numbering in here.
One is that this information about the prefix and the separator works on a package by package basis.
So if you want different numbering on one set of requirements than in another, you basically sub-package them here.
And the other is there's a really useful feature in Cameo for resolving gaps in the numbering.
But it's hidden very carefully.
So watch closely now. Do you see there's this little button called details?
If I click that details button, it unlocks a bunch of hidden functionality.
And if you get to where you have, you know, your numbering is going one, two, three, four, six, seven, eight, and I guess I can create that condition and then show you this, okay?
So let's suppose I delete this requirement five.
And you don't necessarily have to follow me here, but you want to at least watch me.
So I deleted requirement five.
And then I'm going to create three more.
Requirement six.
Requirement seven.
Requirement eight.
And I'm going to re-enter the name real-time display here.
Then I'm going to go back and delete six and delete seven.
Then I'm going to go back into my requirements numbering.
Which I have to get into this way.
And now I have a problem one, two, three, four, eight.
Well, I can decrease eight. It'll go to seven.
And I can do that a whole bunch of times.
But a lot of times you're going to get to where, like, the numbering is just messed up.
And what you want to do is use this function called renumber recursively.
And that will remove gaps in your numbering scheme.
The other thing I can show you about requirements in Cameo is if I use a containment relationship.
OK. So let's suppose I decide that real-time display is actually something that belongs to user interface.
So I can use containment, which shows up here, and I can make real-time display be part of my user interface.
So I'm going to show you another useful trick in Cameo.
You may want to follow me on this part.
So first of all, if I just pick containment off here.
So in this case, when I'm drawing it top down, it's the correct direction on the containment.
But a useful feature to know, and that actually doesn't work on my keyboard because I'm on a Mac keyboard,
but the control key will reverse the direction of that if you do it while you're drawing it.
So now you notice when I did this, it changed my requirement number from eight to be 3.1,
which in most cases is kind of what you want it to do.
So when I say that this requirement is contained within that requirement, it'll actually renumber it.
If I look at my table now, what you see is that three now has this little plus sign underneath it,
and I can expand that to see 3.1.
So those are just useful things to know about working with requirements in Cameo.
I can now, yeah, you're a little bit faint, but I can hear you.
So you said the control key will reverse the direction while you're drawing the relation on there?
I think it's a control key. It's either option or control or one of those.
Okay, yeah, control just adds a pivot point for me.
Yeah, it might be the option key. It might be the, you know, unfortunately, this working on a Mac and having a PC keyboard in here.
It looks like it's the alt key.
Yeah, and I don't have an alt key on my Mac keyboard. That's why.
So, yeah, you can, and there's two kinds of containment.
Like if you try and draw it from here, from the little quick link menu, there is generally a containment that way.
And there's also usually a second one that goes in the other direction.
In fact, usually when I work with it, there's a little menu here.
Maybe they kind of, so we're running 2024 instead of what I usually run, which is 2022.
And maybe they finally decided that's really confusing having two containment and they just switched it.
So just as well, because this one is the one that you usually want, because you usually want to draw them top down.
Yeah, none of my keys are working for that.
So I kind of left that lab to be a little bit free form.
But I think if you've done this and made a table and you see how the table works.
Oh, I should also show you about the columns field in the in the table.
This field here called columns lets you add or remove columns from the table.
So if I want to put like satisfied by in here.
Now I've got another column here.
So you can use columns to control.
These are these are kind of all the fields that you have built in to to your requirements element.
And so you can also create new columns and do things like that.
But but as a quick intro to the requirements editor, that's probably sufficient.
One thing that you want to be aware of, see if I can manage to do this.
If I shrink my cameo window.
If you shrink this window horizontally, this little columns tab will disappear to save space.
And it'll be replaced by like two little carrots.
And you have to know that to to find that table.
So something to be aware of.
Anything else you would like me to tell you about requirements?
Otherwise, I'm about ready to move on to talking about use cases.
And if there's anything else that you would like me to.
To tell you about requirements, I am happy to do it seems to let me.
Stretch my window down, but not not horizontally.
That's probably just a feature of the amazing Mac book stuff.
Yeah, I mean, their their virtual PC environment seems to work pretty well.
So I have I have no complaints about it so far.
It's been working.
Really pretty well, I think.
All right.
Anything else you would like to discuss with.
With requirements here.
Mostly that chapter is about how to use AI to to discover the requirements.
So would the way how you're like discovering requirements, you would just like copy paste that table into the requirements table.
Yeah, that's probably the fastest way to.
To get them in there, I think you have to get it into a.
A CSV kind of.
Representation like out of Excel or on a word.
And then I've seen them paste in after you do that.
So you sort of have to go from.
Chat GPT into kind of a comma separated file.
And then.
From there into the cameo.
And you probably have to match the number of columns.
In your requirements table.
To the number of columns that you have in.
In your table out of chat.
Okay.
Does anybody need another break before we go into use cases? Are you guys good?
Okay.
All right.
So if anybody if no one has objections, I'm going to go into our next.
Slide deck here, which is on.
Use case model.
Sort of slide zero in this slide deck.
Is that if you just ask.
AI to tell you about use cases.
You might get.
Business use cases.
Okay.
So when I just said, give me the use cases for an electron microscope.
It told me all the ways that you could use an election.
And that wasn't what I want.
What I wanted.
So I asked it to tell me about software system use cases.
And you'll notice now.
It's giving me software slash system.
For our electron microscope and.
When you write use cases, they really should be verb phrases or when you name use cases.
They should be verb phrases.
So what goes on your domain model are nouns.
Things.
What goes on your use case diagram are verb phrases and.
What goes in your requirements are shell statements.
And so.
We'll come back and draw this diagram in a little bit.
In cameo, but here's the top level use cases that gave me for.
Operating.
Our electron microscope.
And as I said, we'll.
I'm going to go through the PowerPoint and then we'll do this as a lab.
At the end of the lecture.
And then that'll be about as far as we go for today is to.
To get through use cases.
We've got.
12 slide decks to get to in three days.
And this is slide deck number five already.
So we're just fine in terms of.
Time and coverage.
And.
So you'll see that some of these use cases are for.
Hardware related things like moving the stage around.
And adjusting the beam parameters.
Easily using the operator control interface.
And then some of these use cases relate to image processing.
Which is more the user of the electron microscope from a.
Science standpoint, right? Someone who wants to actually.
Look at an image and do something with it.
So there's kind of two sets of use cases in here.
And then actually a third set.
Which is to calibrate the system and make sure everything is working right.
So there's admin stuff.
To update the software, manage users, things like that, right? So.
These are the scenarios of the system being.
Operated.
So this is one of the first things I tried with chat.
Gbt was I tried to just.
Ask it to write the narrative for a use case.
And I was kind of stunned.
Because.
My reaction was like, holy crap, this thing writes these cases.
Really fast and at an amazing level of detail.
And if you've ever tried to get systems engineers to write use cases.
It's like pulling teeth.
Okay, it's systems engineers.
Basically don't like to do this.
And one of the reasons they don't like to do it is it's kind of a lot of work.
Right. It's real work to actually.
Write this.
Write all this stuff then.
And so by default, what chat Gbt will use.
Is a very long and robust use case template.
That was originally proposed by a guy named Alistair Coburn in his book about use cases.
And he calls these fully dressed use cases.
And one of the reasons that people like this template is because.
It has sections in it for preconditions.
And post conditions.
And it seems very complete.
Well, I never liked this template myself because it's too much work.
And when I started asking AI to write the use cases.
It was kind of like, wow, this isn't really a lot of work anymore because AI will just spit this out.
But I decided I still don't like this kind of big huge template.
Because it's actually a lot of work to read the use case descriptions when they're written in this template.
And I could tell you from some 20 or 30 years of teaching people how to write use cases.
That what people typically do with this.
Long template is they kind of get the most important part, which is.
The sunny day scenario in the rainy day scenario.
Well, I didn't skip it because.
The sunny day scenario here is my main success scenario.
And.
Here's my extensions.
Here's my alternate flows.
So it kind of covers all the detail.
But it's still a lot of work to read it.
And so.
I sort of.
Poke a little fun in my book at what.
Alastair Coburn calls a fully dressed use case template.
And I raised the question about whether.
This guy is fully dressed or if he's overdressed.
And.
If he's walking on Waikiki Beach in his snowshoes and parka.
Then he might be overdressed.
Although.
If you believe that the ice age is coming, then he might be fully.
So fully dressed or overdressed is kind of a subjective question.
And one of the cool things about AI is I can say, make me a picture of a guy.
In snowshoes walking on a frigid Waikiki Beach and it'll do it.
So I had a little fun doing that.
But I like a shorter, more concise use case template.
And so.
I wrote I had it rewrite the use case template after.
Reading my books about use cases, and I said, I want you to use the template.
That I used in my book and told it what page.
And now it writes the use case in a.
Shorter, less verbose style.
And one of the things that I noticed, which I found was really interesting and curious.
Is you notice there's seven steps.
In the sunny day scenario of this use case.
Well, I guess this is a different use case.
So but there's 14 steps in it.
What I noticed is when I asked it to write the use case.
In a shorter template, it omitted about half the steps.
And what it was doing before was it was.
Specifying a bunch of kind of internal details like I don't know if you can read this.
But in step number eight here, it says the software communicates the focus settings to the instrument.
That's kind of internal detail within the use case.
That you can really leave out of a use case description.
So.
I continue to like the use cases better.
Using a less verbose style and.
One of the things that I noticed here when this use case came out came out of chat GPT.
Was that there was no exception behavior in this use case.
And having taught use cases for many, many years.
That's always a red flag for me when I see no exception behavior.
So in fact, what it did.
Is it kind of misnamed my exception behavior to be alternate behavior.
But you always want to be suspicious.
Of a use case that.
Has no exception behavior in it.
So basically, I will write the use case narratives in any style that you like.
And you can pick the style that works for you.
You're taking the class from me, so I get to inflict my opinion on you about what I like.
But I think a use case written at this level of detail is much more readable.
Than the big verbose one.
And what typically gets done on most projects.
Is because people hate writing use cases, they just skip it.
They skip writing the narrative English version.
And they go directly from the use case diagram.
To usually activity diagrams.
So you can elaborate a use case on.
Either an activity diagram or a sequence diagram.
But usually it's done on activity diagrams.
And if you follow magic grid, they will tell you to start doing functional analysis.
Immediately underneath these cases.
So they basically treat.
The use cases as high level functions of the system.
And then start drawing activity diagrams and decomposing activities into child diagrams.
Sub sub diagrams.
And in my experience, that's where you start spending a lot of your modeling time on activity diagrams.
So if you have experienced.
And I think at least one of you said, yep, we got this problem.
Where the activity diagrams take up all your modeling time.
It's probably because they are treating your use cases as.
System functions.
And not actual proper use cases.
And then using those high level system functions to do functional.
And so we're kind of in philosophy land here.
But.
I think it's worth talking about.
What's the difference?
Because a lot of people don't understand.
What is the difference between a functional decomposition and a scenario decomposition?
And so what a use case model is supposed to be.
Is a scenario decomposition where you're talking about.
The system from the perspective of the user.
As opposed to a functional decomposition.
Where you're talking about the system from the perspective of the system.
And what its functions are.
Everybody clear on that?
Because I think it's a really important.
Distinction.
So when you.
Attack use cases.
From the user perspective.
Then what you focus on is.
What actions can the user take.
That are different from that main.
Basic.
Typical usage.
Sunny day scenario.
That's your alternate behaviors.
And then what errors can happen.
What exceptions can happen.
During that use case.
And it's really identifying the alternate and exception behaviors from the use case.
That.
Kind of.
Set it apart from a functional decomposition.
If I pop back to my.
Requirements lecture here for a minute.
Remember we were talking about zigzagging to use cases.
And focusing on alternate and exception behavior.
And.
That was this chart here.
Where we identified all the alternate and exception behavior requirements.
So if you go straight to a functional decomposition.
And you don't use your use cases.
To identify this alternate and exception behavior.
Then what happens is in your requirements model.
You don't have the requirements for the alternate exception behavior.
Of these cases.
And.
So there are.
Big advantages to.
At least in my mind.
There's big advantages to.
Actually using the use cases properly.
Any questions on this?
I.
I tend to get up on my soap box about it.
But I do think it's really important.
So.
Whereas the typical.
Usage of activity diagrams in SysML.
Is to decompose functions.
What I like to use activity diagrams for in SysML.
Is to detail out the alternate and exception behaviors.
So it's a.
It's a difference in usage.
You know it's still a yellow use case bubble with an activity diagram inside it.
But what's on that activity diagram is going to be a little different.
Depending on whether you're treating your use case as a system function.
Or whether you're treating your use case as a scenario.
So I'm not hearing any comments.
I don't know.
I don't know what you're thinking about this lecture but.
I'm just going to continue with it.
You can tell me after the lecture what you thought about it.
Or you can interrupt me at any point.
So.
And I kind of mentioned this during the requirements chapter.
Is when you're putting your requirements together.
You don't want the requirements to be all full of holes.
It's.
It causes a lot of trouble if your requirements.
Are incomplete.
And if you don't analyze the sunny day and rainy day.
Behavior in your use cases.
Then you're going to get Swiss cheese.
So you're really not done.
If you haven't considered.
The rain nation areas.
Mark you're going to say something.
Sorry you have that activity diagram was interesting.
I have not seen that before.
The structured branching.
To handle the fail.
The rich capture fail.
Yeah so I actually there's a feature in cameo.
That no one ever talks about and no one ever uses because the feature itself.
Is buddy.
I'm going to show it to you and then I'll suggest that you don't use it to draw your activity diagrams.
But it actually generates them this way.
So.
If you don't write your use cases to consider.
Alternate and exception behavior.
You're going to miss all these requirements.
And you can try this prompting yourself.
But or you can take my word for it you miss a lot of stuff.
If you don't consider your rainy day scenarios.
You can also.
Do your activity diagrams and put requirements on them.
And then you can say you know if the position of my stage.
Is not correct.
I have to adjust that stage position.
And I have a requirement here that says I need the ability to reposition the stage.
And I can say that this thing.
Refines that requirement.
Okay.
So you don't always have to put.
The requirements on the activity diagrams but you certainly can if you want to verify.
That you're covering all you know everything that you need to cover.
You can also elaborate your use case.
With a sequence diagram instead of an activity diagram.
And if you do that in an object oriented design approach.
It will help you link your.
Functions to your box your operations and I'll show you later when we get into.
Sequence diagram lecture.
How to do this.
But how I what I like to do is I like to use.
The activity diagrams to.
Make sure I've identified my alternate and exception behavior.
And then I like to use sequence diagrams.
To actually put that behavior on the appropriate blocks.
So.
Here's a template.
That I like to use.
And.
Remember when I trained my agent Obi Wan.
This is one of the books that I had him read.
And then later I found the page number in that book and I said.
See how the use case is written in this book.
On page 270 whatever.
I want you to always write your use cases that way.
And I learned.
Very quickly.
And so now.
In Obi Wan's training he knows.
That whenever I ask him to write a use case narrative he's going to write it in this format.
And just to understand what the format is.
2A is an alternate off step 2.
And after I finish 2A.
It rejoins at step 3.
4E is an alternate off step 4.
And when it's resolved it rejoins.
Back at step 4.
And tries it again.
So this format allows you to basically.
Generate an activity diagram for your test team to use.
Where they can step through all the branches of the use case.
And test the system behavior.
And you can do something as simple if you're training chat GPT.
Yourself you can create a custom GPT file.
Take a screenshot of this PowerPoint slide.
A screenshot of the little white block with the format in it.
And say I want you to use a template like this when you write a use case.
And pretty much it will do it.
So you can teach it.
And you don't have to use my template.
You can make a template for your own.
Maybe you like to always show the preconditions and post conditions.
But you can basically train AI to write use cases.
In the style that you want them written in.
And that's really pretty cool.
Having trained some thousands of people on how to write use cases.
It's a lot faster to train AI.
Just like say do it like this.
And it will figure it out and follow it.
It will just write them in there.
So AI is really cool for writing use cases.
And the number one objection that people have to writing use cases is that it takes too freaking long.
And it doesn't with AI.
It will write them very quickly.
Now you still have to check it.
But it is a lot faster than starting from scratch.
So another thing that you can do with it's not exactly part of use case modeling technically.
But it kind of goes hand in glove with use case modeling.
Is you can start asking it to identify all the screens of your system.
And it will be just like show me the screens for image processing.
And it will tell you exactly what screens you need.
What each one of them is for.
What kind of UI widgets you want on it if you want to do that.
But it will tell you what screens to build.
And it will make you wire frames or story boards of those screens if you just ask it to generate a wire frame using HTML, jQuery, mobile, and CSS.
Because AI generates HTML very well.
And jQuery, mobile has been around long enough that AI understands how to generate web pages with jQuery and HTML.
So when you're modeling your use cases, especially if they're software use cases, it's really useful to let AI mock up your screens.
And then you can check what's on this screen, like what buttons are on here.
And what menu options are on the screen, all your user interface widgets.
You can check that against the use case narrative and make sure that that's working the way you want it.
So that's going to bring us to the last lab of the day.
And that lab is going to be, to start with, to draw this use case diagram.
So I'm going to go back over to Cameo and start doing that.
And here's how we're going to do it.
Use case diagram in the PowerPoint somewhere?
Yeah, it is that slide.
Slide, four of these.
Okay, got it.
Got it.
Thank you.
Yep.
So here's how we're going to make this.
We're going to, and actually Maria had a good idea, which is make sure your model is saved at this point.
So hit the little floppy disk icon there.
And then we'll save it again after this lab.
So when we come back tomorrow, you'll have your conceptual model done pretty much.
So we're going to create a new package in here.
And we're going to call it Use Cases.
And you'll notice, by the way, that my package structure is starting to fill up here.
So now we're going to go make a use case diagram inside of that package.
That's a SysML use case diagram.
And then I'm going to count for you so you don't have to.
We got five, ten, I got like 14 bubbles on there.
So clearly this is a job for the sticky button.
There is an alternative that's potentially faster.
If you were to, if you had all those typed out, so it might be easier to type them out into a text file or Excel file or something like that, you can just copy and paste them in as use cases.
That way you don't have to paste them in and then type in the names.
I'm sure you're right, but I don't have them all typed out.
And I want to show you how to write them anyway, which is something that most SysML training courses don't even bother to do is teach you how to actually write a use case, which of course bugs me no end.
So now I've got my diagram kind of laid out here.
And most of the time I'm just going to use regular associations to connect these guys.
So we might as well start naming things.
This is my operator.
That is control instrument.
This is process and analyze images.
And there are a couple of other relationships that are the standard ones to use on use case diagrams.
One is called include and the other is called extend.
This diagram doesn't have any extends on it.
But I'll probably show you how to use it anyway.
Extends is one of the most confusing elements of use case modeling.
Also, I don't know how much I've shown you the layout techniques, but if I haven't shown them to you, I can show them to you now.
So on this layout menu item, I have an option to center all these vertically.
And it's actually quite amazing, but neatness really does count in your SysML models.
So it's a good idea to get into the habit of using those layout tools.
So now I'm going to use include relationships between my top level use cases and the ones on this side.
And I'm going to have a whole bunch of includes.
And I'll explain to you what includes means in a minute.
But I'm going to use my sticky button and draw these includes.
One of the things that I hope comes out of this class is that you kind of come away with a feeling of
how to be pretty efficient in drawing with Cameo.
So it is perhaps a big enough exercise to do that.
I got to go back and use regular associations for these two.
It's getting close to the end of the day.
I'm getting a little punchy here.
But we'll be done in a few minutes.
So we can manipulate the stage.
We can select an imaging mode.
So by using includes, what we're basically saying is that these use cases are kind of part of this use case.
Okay.
I had one I had one extra one.
Okay.
Looks like you're doing good.
We'll give you a minute and then I'm going to show you how to use extends.
All right.
So I'm going to assume that you're either done or close enough to done to let me introduce
something new here.
So we kind of already introduced includes and that just means that these are parts of the higher level use case basically.
The reason includes got the reason includes exist is mostly for reusing a scenario that's going to appear in multiple use cases.
So that didn't happen in this case, but we can still use includes to do it extends tends to be a very confusing construct in in modeling use cases.
But it's normally used for exception.
And the best way I can give you to think about it is suppose I'm trying to store data here and my storage is full.
Okay.
Or maybe I'm trying to retrieve data and my connection is down.
Okay.
So those are two different ways that this use case might need to be extended.
So I'm going to use extends and show you how to model that.
So first of all, I'm going to make two use cases here.
And I'm going to call them and all full storage.
And recover from lost connection.
So when you use extends, there's a concept called extension points.
And it means that when you're writing this use case, you have to handle there.
There's a point where this use case might get extended with whatever's in here, and it's not in your normal behavior.
Sunny day scenario, but it's something that's going to require handling.
So when you draw the extends, you generally draw it in the backwards direction from the includes.
So let's see if I do this right.
If I start this from here, I'm going to draw the arrow this way.
I start from the child and I draw to the parent.
Once I click, it says, hey, there's no extension point here.
Do I want to add one?
And I'm going to say yes.
And the extension point is storage is full.
And so the way you read this is that when I'm executing this use case,
if I run into the condition that my storage is full,
then I'm going to go jump into this extended use case for handling.
So I'm going to do it once more just so you've seen it twice and you can try it.
So now I'm going to recover from a lost connection.
So I'm going to take my extends arrow, start it here, draw it there.
And in this case, it's not the same extension point.
So I have to create a new one.
And this is connection loss.
And now my use case has two extension points in it.
One for when the storage is full and the other for when my connection is lost.
And then how I handle that error condition is going to be described in here.
I can't quite see if you guys have done that already.
So this is going to be the last thing that we do today.
Okay, I think in the slides we've kind of written out the detail for this acquire images use case.
And so I want to show you how you can go and specify that.
You guys all done with extends at this point?
Okay.
So let's go do acquire images.
So now we get a bunch of options.
So I've opened up the use case spec.
And probably what you're going to wind up doing is just typing the use case in here in this documentation.
I do want to show you this other feature and then I'm going to recommend that you don't really use it very much or you don't use all of it.
And I'll show you how to use it and then tell you that unfortunately the tool is buggy.
And if you use this this feature, it's kind of at your own risk and I don't recommend it.
But I'm going to open up this thing called the use case scenario sketch.
And the reason it's worth showing you is that this is actually the right idea about how to specify use cases.
Unfortunately, their implementation is pretty flawed.
I'm going to show you how to do it anyway.
Because I'd rather you know how to think about writing a use case.
And then once you understand how to think about it, you can just go back and write it in here.
I have not heard, but this is my first time using 2024 so we can find out.
I I suspect it hasn't because I actually met like the so project manager for cameo over at that and cozy conference in Hawaii about a year and a half ago.
And I kind of leaned on him a little bit saying, hey, this feature is almost really great.
Can you fix it?
And he was sort of like, no, nobody writes use cases anyway.
We don't want to bother.
We got more important stuff to do.
So I don't really expect it to be fixed, but we'll try it and see.
And so now what we're going to do and again, I'm working kind of from from here.
I wonder if I can leave this on the screen.
Maybe I can leave it on the screen.
Well, at least if I do it this way, I can just pop back and forth.
So I want these seven steps in my basic course.
And if I use this feature, it's going to number them for me.
So I'm going to click plus in here.
And it says the S.M. operator initiates the acquired images.
And I'm going to hit plus again.
And it says the system prepares the imaging subsystem.
But kind of just keep hitting plus here.
And you notice it's numbering these steps automatically.
And now it says.
Imaging parameters.
It has a system validates the parameters.
So I'm going to pause here.
And now, if I go back and look at my description.
Add this.
This behavior, which says it's an alternate flow, but it's really an error message.
So it's really an exception flow.
OK.
And so what I'm going to do is with step four selected.
I'm going to select that and then go to exception flow here.
And now I can add the type or a step.
So the type is invalid parameters.
Now I can specify the step here.
And the step is operator fixes the parameters.
And then my next step is going to be.
Rejoin at step five.
So now I've done this.
And now I'm going to show you what would be really cool about this particular feature if it worked right.
But this is where it's buggy.
OK, so if I click open and update here.
What it's done is it's actually created.
This activity diagram.
So.
What's cool about it is that I only have to type it once and it actually creates a diagram.
Unfortunately.
It is.
Kind of.
Almost correct, but not really correct.
OK, so it'll say rejoin at step five, which would be here.
But if I try to actually correct this diagram to have this link up here.
It's liable to mess up my use case text.
OK.
And if you do any kind of serious editing on this diagram, it's liable to crash cameo and.
Destroy your use case text.
So because of that reason.
I kind of recommend that you don't use this, even though it's kind of.
Very tantalizingly close to working correctly.
This capability is something that.
I don't know if you know about sparks enterprise architect, but it's sort of a competitive.
Tool to cameo and when I wrote my book design driven testing.
Which I think I have the book cover here in my slides.
I actually went down to Australia and met with the sparks people.
And.
I guess I don't have it there.
But they actually built this capability to generate.
An activity diagram from the use case text in sparks.
They call it a structured scenario.
And the sparks implementation of this works correctly.
So I kind of tried to copy that feature.
And then I suppose just lost patience.
With it and never really finished it correctly.
So.
It's a really cool idea.
But I sort of recommend that.
Instead of and now by the way.
I just go straight to the activity diagram if I click on that.
So to get into this use case specification I have to go back here.
It will let you.
Change the text here.
So if I click on for.
Exception you see it's there.
I click on two it's not if I click on four it is.
So this is a really good way to think about use cases.
And if cameo worked better it would be a really great feature to use.
But.
The world being what it is.
It's kind of like I can show it to you but not really recommend that you use it.
I would recommend that you write the use case in this format.
And you just do it here in the documentation.
And I wouldn't number any of your steps until the end.
And I kind of write it in a block of English.
Just that looks like.
That.
You know from here you can draw an activity by hand an activity diagram by hand pretty easily.
And.
It's the best guidance I can give you.
I can't in good conscience.
Tell you to use this feature because I think you'll wind up unhappy.
And I don't want you unhappy with me for telling you how to you know that you should use a buggy feature of cameo.
But it is really in my estimation the correct way to think about use cases.
So that is all I plan to cover for today.
We are nine minutes.
Before five.
I'm going to stop sharing my screen.
And then if there is anything else you would like to cover.
I'm happy to chat about it.
I really wish I could tell you that feature worked.
Because it would be really cool if the feature worked but it almost works.
Sometimes almost working is better than not working at all.
I feel like it would be just one more parallel option that would kind of compete with sequence diagrams and activity diagrams.
And there's just so many, you know, so many diagrams and views that you can create.
You know, the same thing that just becomes this massive program with all these different opportunities and options for representing a system that, you know,
makes it difficult and I guess very artistic in which way you decide to go.
Yeah, well, if it worked right, it would save you a ton of time drawing activity diagrams.
Because it does generate the activity diagrams from the use case narrative.
But because it doesn't work right, generating these case diagrams is not quite viable.
So you can basically draw your use case diagrams by your activity diagrams by hand.
But you're better off, in my brain, you're better off writing the use case in that style and then using that to draw your activity diagrams from.
That's how I would do it.
But, you know, I have another comment slash question.
You mentioned earlier that, you know, people spend a lot of, when they do the functional decomp, that's something that I know our company does a lot.
You know, you just get into this endless cycle of decomposing activities into lower level activities, into lower level activities.
And then at some point, you know, for us, we're trying to cut off drawing these lower level activities into, okay, now the next level of lower level activities are going to be software activities.
Do you have any thoughts on that? To me, it's just, it is this ever extending arm of activities that just goes, you know, in levels deep.
Yeah, well, a lot of your activities are going to be software activities, and they don't necessarily have to be very deep down the tree.
But what's what takes a lot of time in cameo is once you start putting object flows on your activity diagrams, then it puts pins on all the activities.
And then you have to name all your pins with input data and output data, and they get propagated onto the child diagrams as activity parameters.
And you're spending all this time thinking about inputs and outputs. And that's where it starts to chew up lots and lots of your time.
So it may be that even, you know, your higher level activities are software activities.
But there's faster ways to figure out your input and output parameters than doing it with object flows, pins and activity parameters.
The pain level goes up a lot when you start putting object flows on your activity diagrams.
So what would you suggest as an example to, you know, as a more efficient way, that's definitely something we have a problem with.
Because, you know, once you start doing that, especially when you have a whole lot of modelers in there, and somebody goes through an object, updates one object flow on one diagram,
and then that causes a problem on the next level up and the next level down, and then you got to go through and modify it on that.
What that causes, you know, just pushes that error all the way up and all the way down.
Yeah, and you spin your wheels literally for months on that stuff.
And I wish I was exaggerating when I say months, but I'm not.
Okay. You can spin your wheels on that for a long time.
So the way I do it personally is I don't put object flows on my activity diagrams at all.
I just use control flows.
And that's kind of back to the original intent of activity diagrams, which is kind of like to put a little flow chart in there.
Right. And so it's kind of a radical proposal maybe to some people.
But you'd be amazed how many problems it solves if you don't put the object flows on the activity diagrams at all.
Then you don't have the input pins, you don't have the output pins, you don't have the activity parameters.
And when you turn your activity into an operation, you just put in the parameter list of that activity, what are the inputs and what are the outputs.
And I'm actually kind of right now, my co-author Brian and I are actively considering writing another book, which is going to be called Pain-Free MBSC.
Okay. And that's one of the things we're going to propose in Pain-Free MBSC is since this is where you burn all the schedule time, just don't do it.
That's a great idea. If you can somehow get a hold of money saved by using that approach, I would love to use that as ammunition to change the system.
Well, it's going to be different for every company and they're probably not going to share that data with me.
But, you know, if you just kind of think about it intuitively, do you need to specify your inputs and outputs? Yes, of course you do.
Do you need to do that on activity diagrams with object flows, pins and activity parameters? No, there's other ways that you can specify the inputs and outputs to your functions.
That is the slowest and most painful way that I know to specify inputs and outputs. And it's because, you know, I'm a software guy, right?
And as a software guy, you would just never do that. You would never draw a diagram because just to specify an input parameter, okay, I have to rename the input pin.
And then I have to go and, you know, look at a child diagram. And then I have to give it, you know, a type. And it just freaking takes forever.
Okay. So, you know, and then what you get, and it's just what Daniel is describing, you get all these item flow violations.
And somebody renames one somewhere and everything breaks. And everybody's just like running around.
I'm going to use a politically incorrect term, if you'll forgive me for using it. But we used to call this a Chinese fire drill.
Okay. And it's like everybody's running around fixing these errors. And it wastes incredible amount of time.
So for me, I like doing activity diagrams. And I kind of just say no to the object flows, right?
I just think that in theory, it's a good idea to do all this with object flows and activity parameters in practice.
It takes forever. So I'm kind of radical, you know, about some things.
And but what I've been thinking recently, and this is kind of a new idea, like a couple of days old, to write this thing called pain-free MBSC.
It sort of hatched on me when I was teaching, I was in New Mexico last week teaching an on-site class because I'm doing some teaching for Caltech now and they sent me out there.
And I was kind of going through this with people.
And then somewhere as the class was wrapping up that day, one of my students said something about, oh, you have this nice pain-free way of doing it.
And I was actually on the airplane flying home. And it dawned on me that pain-free MBSC has kind of a nice sound to it.
And I thought, well, maybe it's time for the next book and maybe the next book is pain-free MBSC because there's a similar thing that you'll see with IBDs where there's a way to avoid wasting all your time with IBDs.
And it's, you know, my experience is I taught hundreds of people at Boeing and other companies teaching from DeSoe course materials, from Boeing course materials, from Enola course materials.
And everybody always got stuck in the same places. And it's usually with the object flows and it's usually with item flows on IBDs.
And we'll talk about that one tomorrow because it's when people try to do their item flows and they haven't defined their interface blocks, they get in trouble and they wind up chasing their tail around item flows again.
But that's, you know, when I've taught classes like this where we have labs, I know where all the students get stuck.
And then when I worked at that company with Brian, they didn't really know what to do with me when they hired me.
So they put me on helping a couple projects clean up item flow violations.
And it was just horrific. You know, they would give me these diagrams all full of red ink and tell me like, go fix all these violations.
And I tried to say, you know, you can evaluate all of these item flow violations, but they didn't want to hear it.
So I wound up not working at that company very long, but happily I met Brian when I was working there.
But there's like two or three places in System L where the practices people follow result in 80 percent of the wasted modeling time.
And so when I built this course, I left out those places where you get stuck.
I just didn't put them in the methodology and the process at all.
And those are the two main ones. One is the object flows on activity diagrams and the other is trying to do item flows before you defined all your interface blocks on IBDs.
And I'm telling you, 80 percent of the trouble with the System L models come in those two places.
Well, you know, I always write books when I when I have a battle to fight and I don't want to, you know, go butt heads with anybody.
I just write another book. This is my ninth one.
So, you know, so you can do it the pain free way or you can add your pain back in if you're really, you know, so so in love with the painful way of doing things that you can't give it up.
But it really doesn't buy you anything extra.
You still get the inputs and outputs on your functions.
You just do it in a less painful way.
Thank you. Yeah.
So I hope that helps. We are four minutes after five.
So I think it's it's time for us to wrap up.
We'll pick up tomorrow again at same time at 10 o'clock and we'll start talking about logical architecture.
And we'll go from that domain model into a logical architecture.
That's the third place where people waste a lot of time is trying to do logical architecture on a black box.
It's like I have this black box. Tell me what the architecture is.
I knew that. That's hard. Right.
So we'll do that the easy way tomorrow.
Sounds good. Thank you very much.
OK. You guys feel like this is on track?
You getting useful information here?
Yeah, I'm really, really enjoying the last 30 minutes.
That was a great conversation.
And you really have some some great ideas that would tremendously help us.
Well, you know, the old cartoon, right, is the guy goes to the doctor and he says, doctor, every time I bang my forehead against the wall, it hurts.
And the doctor says, well, stop banging your forehead against the wall.
That's pretty much the way I teach this stuff. Right.
It's like, don't do the things that cause you all the pain and you'll have less pain.
So that's my two cents.
Elena, you good?
All right. We'll see you all in the morning.
All right.
Good night. Oh, save your cameo models before you before you leave.
I'm going to leave my connection to that virtual machine open overnight.
Save your cameo models.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
to let him back into the fight.
Pan presents Alexander with a bold plan of attack.
While Laji fights his way towards Messina from the south,
Pan will lead the 7th Army on a dramatic race
towards the capital city of Palermo
along the northern coast of the island.
If taken, Palermo will offer the allied fleet
a vital base of operations.
Alexander doesn't trust the American capacity
for waging war, really.
But he's thinking, if I say no,
I'm happy to do it anyway.
So he says, okay, he says,
you can take a reconnaissance force,
which in military terms means
a large scouting party.
It's the beginning of what becomes
a great sweeping movement
towards Messina.
Pan divides his forces into two major fronts.
General Omar will lead one American corps
to the north of the town of Nicosia,
splitting the island in half.
At the same time,
a second corps of armor and infantry
will begin on charge of Palermo itself,
with Pan in the lead.
The first capital we want to get access
to a controlled country,
taken by Patton, was a prize
that George Patton could not
have possibly imagined.
If Patton's army succeeds,
the capital city and the entire
western half of Sicily
will be in American hands,
and victory will be his own redemption.
Patton's army heads for Palermo,
loaded for bear, and ready to meet
the enemy in battle.
Finally, Patton is leading the kind of attack
he craves, a swift assault
and a full strike on the heart of the enemy.
...technology to prevent thieves from
stealing your wallet and stealing your info.
Having your information stolen
is a nightmare, but with
Slythmin, I know I'm going to die.
With bunny clips, cash can easily fall out,
but with the auto-locking Slythmin,
your cards and money stay securely in place.
Then just press the button to release the lock.
Slythmin is ergonomically designed
to optimize space and keep your belongings
organized. It has a built-in cash clip
and a flexible outer band
to securely fit your additional cards
and your extra cash. Even with everything
you see here in the Slythmin, it's still
ultra-thin. Both key wallets
are fun and comfortable, but the Slythmin
is so compact it fits in any size
pocket. Plus, it keeps everything easy
to access. The Slythmin holds everything
from pictures to credit cards to
driver's licenses. Yeah, it's still so
fit. Same vibe I do,
bent cards and damaged magnetic strips.
Slythmin keeps them protected, gets
crush resistant, and can really dig a
beating. Similar wallets over
$100. But color-clipped now
against Slythmin were just $29.99.
Over the next five minutes, they'll
get an instant $10 discount.
So it's only $19.99.
But wait, due to pricing costs and
supply chain shortages, this may be your
last chance to get Slythmin at this
low price. There's a strict limit of
free Slythmin wallets, while supplies
last. You still have time to get your very
own Slythmin wallets, but you must
act fast. Talk with
order now. Call
1-800-841-3505-05. Call
businesslythminwallet.com.
So call
1-800-841-3505-05.
Order now.
Attention!
If you or a loved one were diagnosed
with mesothelioma or lung cancer
after being exposed to
asbestos, even if you smoked,
call the victim's justice group now.
You may be entitled to money damages.
A $3,000,000 full-order trust fund
has been set aside for mesothelioma and
asbestos patients and their families.
Since the 1970s, many companies
did little or nothing to protect workers
from dangerous asbestos exposure.
Asbestos exposure can be devastating
and may have occurred while performing
work in these industries and trades
listed on your screen. If you worked in
many of these industries and were diagnosed
with mesothelioma or lung cancer,
call the victim's justice group now.
The average mesothelioma claim is more
than $1,000,000 and often
received in less than a year.
If you or someone you loved worked in
many of these industries and trades listed on your screen
and was later diagnosed with mesothelioma
or lung cancer, even if you smoked,
call the number on your screen
right now to get the help and financial
compensation you deserve.
The M1A1A-1 main battle tank
is one of the toughest
and most lethal killing machines
on the battlefield today.
Yes, sir. It's main objective
is to go out and rip holes in the enemy's armor
like a can opener and then attack them.
Fire!
From the teachings of growth to the modern
ruling, experience the soul
that is based on modern materials.
Just days after fighting his way
off the beaches of Sicily,
General George Patton's army
is on the move.
Leading an armored charge
on the cattle city of Palermo.
Albert Kessler has no intention
of sacrificing the cream
of Sicily.
He orders the German forces
back to the northeast
to build on the high ground
around Almeda.
Now other
tanks between Patton and Palermo
are disheartened to be
fully trained.
But to the east, as the more
rallying troops push farther inland,
they once again come face to face
with a hardened killer
to return to battle positions.
As the big red one
fights its way through a small town,
Andrew Jameson and his rifle
continue to make their way
up one of the narrow streets
searching for enemy infantry.
Suddenly,
as they approach the town square,
they run right into a Mark VI
Tiger tank.
We saw the AA
coming out of that
street before we saw the tank.
So he comes out
and he takes a look around,
sees what's going on,
and we're all down.
Jameson's platoon leader
calls for a bazooka
to take the Tiger out.
Thinking he might get him out,
Jameson volunteers.
Oh, that thing up there
is so starved.
So they hide that bazooka
and unload it up.
Jameson takes a position
ready to hammer the Tiger
with an explosive round from the bazooka.
Suddenly,
the turret slowly turns towards him.
Jameson finds himself staring down
at the Tiger's muscle.
And I knew he saw me.
So I take off the cover
My role model tells us
you want me to get your silver star now.
Okay.
That was an incident, wasn't it?
Yeah.
Go start your tank and see what I can do.
Years later,
American Union tanks and artillery
come with a ring and cut loose on the Tiger.
Another town
falls to the G office
of a big red line.
60 miles west
a black and silver heart
is all sharing in its glitter heart.
I mean,
there's only a matter of time before you're going to give up.
I mean, who's going to stop?
George S. Patton.
Friday,
on July 23, 1943,
four days after getting off
on his cattle recharge, Patton
had a tryout at 75
Orange Hill, there.
It has garnered great headlines.
As Patton
bests in the glory of his triumph,
word reaches the allies from Italy.
The dictator, Danito Mussolini,
has been ruled from power by
King Emmanuel III.
Mussolini is under arrest and has been placed
in an isolated prison.
The Italian-German alliance
is threatened.
...
...
...
...
...
...
...
...
...
...
...
...
the battlefields of Sicily for himself and the U.S. Army.
And once you have success, you get very hard stuff.
And once you got happy with having success, it was impossible to stop.
Despite the horrific friendly fire tragedy in the skies over Sicily,
that can't be redeemed.
In less than two weeks, we have led the largest American invasion
of World War II yet.
Faced off against the Tigers and the Herbans.
Captured the Captain's second body.
The battle for Sicily is just getting started.
Most of the Germans have gotten by.
And the reason for that is all wrong.
The plan is to fight a retreat that falls back on a series of defenses.
At last, Patton is ready to face whatever castlery and something you have to offer.
In a letter to his wife, Beatrice, Patton writes,
The war is far from over.
We are going to end in a big way.
I have not the least notion what will happen next time.
But I don't care where men or women fight.
So long as I keep fighting,
it is the greatest of all games.
In a matter of days,
the Herbans' army will face their greatest challenge yet.
As the battle for Sicily continues,
its troops must go up against the Athali,
50 miles off fortified enemy highland.
Here, the Germans can block every move that they make.
It will be a race to the finish line of the scene.
The Herbans' army is digging in,
ready for a final test.
From the battlefront to the home front,
the discrete conflict is well-being in Sicily.
In studying the city line,
in dramatic detail,
I saw the heart and I saw the body.
I knew the greatest dream.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Even when the North Africa and Russian fronts began to turn against them
and millions of German bodies littered the desert sand and Russian plains,
Hitler steadfastly ignored the obvious.
His empire was overextended and had far too many powerful enemies.
The German high command was so
that Britain and the United States would eventually launch an attack on Medan, Europe.
The question was never if, but only when.
Despite intelligence reports about massive buildup of Allied troops in India,
when D-Day came, Hitler's defenses along the French coast were unable to contain the advancing tide.
In the initial assault, more than 6,000 Allied ships,
13,000 aircraft, and over 160,000 troops swarmed across the English Channel.
Within a month, a quarter of a million additional men
and an equal number of vehicles were hammered into the water.
With their efforts now split between the Allies in the West and the Russians in the East,
the Germans simply could not resist the onrushing wave of destruction.
Although it must have seemed like an eternity to the Brits and the Allies doing quite well,
success came relatively fast.
By the end of July, the Allies had broken out of Normandy.
Now, British and Canadian forces drove through Belgium
on their way to liberate the Dutch port of Antwerp.
Simultaneously, the Americans fanned out east and northeast across central France
towards Belgium and Luxembourg.
On August 25, 1944, parrots were liberated after all the years of German occupation.
By September the 3rd, less than three months after D-Day,
Brussels was liberated by the British,
and a week later, Americans reached Aachen and the German border.
France had been free, and American troops were poised to cross the sea-free line,
a massive wall of defensive works protecting the Germany's western border.
This is the end of the video.
Thank you for watching.
See you next time.
Thank you.
Thank you.
Thank you.
Thank you.
The Allied invasion is counting the Russian front
and cost Germany more than a problem.
The attacks field up and it's severely crippled the low bar.
The German industry could no longer replace the lost equipment.
Hitler's Germany was being led dry.
This was the monster of shrieking military.
Germany called on every man between the ages of 16 to 60
and shrewdly into the fight to save the party.
But still the Allies came.
By the end of September,
the British had opened the port of Antwerp to Allied shipping,
and less than a month later,
French troops moved through the Alsace region
and stood on the backs of Germany's right wing.
If the German infantry was not unwrapping fast enough in the field,
strife in the high command only made matters worse.
Three weeks after D-Day,
General von Rundstedt,
Hitler's commander of all troops in Western Europe,
resigned in this case.
Two weeks later,
the massively popular General Erwin Rommel also resigned,
leading German troops in occupied France
with virtually no experience in the US.
If Adolf Hitler could not reorganize his army within a few weeks,
his thousand-year life would collapse before Rundstedt.
But there was an array of hope next to the Saskatchewan party.
If the Allied invasion sat straight from the journey,
the speed of their advance would have stretched allies to by-lines
and now passed to the Germans.
The German army would have been defeated
in the fall of 1915.
Addy, to our left France,
by September the days grew shorter
and sunny weather returned constant rain,
reducing their ability to keep pressure
over the retreating Germans.
In November, General George Patton's 3rd Army had reduced its number of missions from an August high of 12,000 a month to fewer than 3,500.
Six months of relentless fighting in marching, followed by months of rain, slowed the Allied advance to a halt.
Hard to believe you can get all this in just...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
It kind of just sort of reinforces that you should always check what AI is telling you.
You're certainly not all redundant.
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
Are you still with us? Did you get called to a meeting or something?
Nope, I'm here.
Do you have the signals done?
We'll just a second.
Okay.
So while you're still working, is there anybody here who's brand new to IBDs and hasn't done one before?
...
Okay.
So I see you're putting them all on the same diagram, the signals and the flow properties.
I might put them on separate diagrams, but that's okay if you want to do that.
Probably a little bit more maintainable if you have your signals and your flow properties in separate packages, but that's fine.
Elena, are you ready to go on to IBDs?
Yeah.
Okay.
So everybody ready?
Then here's what we're going to do next.
So I'll do a little bit of theory discussion on IBDs.
I'm kind of going to assume you mostly all know what they are already, but what you show on an IBD is the interfaces.
And in this case, it's interfaces across subsystems.
Okay.
So you can put lots and lots of stuff on an IBD, and the more stuff you put on it, the more difficult it becomes to read.
So something that I consider to be good practice is to make different IBDs to show different aspects of the interfaces you're developing.
So in the interest of time, we're only going to do one.
And the one that we're going to do is basically to show power coming out of the power supply and feeding into all the other subsystems.
And we're going to show that using the iPower interface.
Okay.
And so we're going to be adding proxy ports to all these other subsystems.
We're going to type the proxy port with the name of the interface block, iPower.
And then we're going to show the actual power distribution flowing across those interfaces.
That makes sense to everybody?
Yes. Yep.
All right.
So how are we going to do that?
We're going to go back to our subsystem diagrams.
You know, looking at this again, it's been a while since I looked at this.
I think some of these signals are the types on the flow properties.
And we maybe need, we might need to go back and add those types, but we can leave them type free for the moment.
So how do we make this IBD?
Again, if this is new to anybody seeing it for the first time, please speak up.
But we're going to go to our BDD, our subsystem BDD, and then we're going to right click on the system block.
And we're going to say create diagram, and it's going to be a SysML internal block diagram.
Now, when we do that, we get this dialog, and it's going to show all the subsystems that we have that we can put on this IBD.
So I'm just going to say OK.
And what I get is I get my subsystem diagram.
Now, we haven't gone and put the parts in the power supply yet.
So let's just not worry about that for the moment.
But I'm going to put my power supply on the left, and I'm going to take all my other subsystems and put them over on the right.
I'll line them all up.
So we'll get a little zoomed in view.
And so what we decided to do, or what I decided to do when I made this example, is to only show power on here.
Because with so many subsystems, if we start trying to show all the different flow properties across all the different interfaces, it's going to really become hard to see.
So I'm going to now go put proxy ports on all of these subsystems.
I'm going to do it with my sticky button, because I like to draw fast.
So I'm going to put proxy ports on all of these.
And then I'll line these up on the edge.
Now the next thing I'm going to do, so I'm going to call this one power out.
And I'm going to call all of these power in.
I'm just going to copy that name.
My command keys don't work.
So when you use ports, proxy ports, and most of the time you're going to use proxy ports, the type of the proxy port is an interface block.
So the interface block that's going to type all these proxy ports, not surprisingly, is going to be the IPower interface.
So when I drop IPower on here, it is going to type those interface blocks.
And you can kind of immediately see that I have a problem with direction here.
So I don't know if you all know about port conjugation or not, but the way you fix this direction problem is you check the is conjugated box.
And then you see this little tilde symbol.
So what port conjugation means, if you think of it, any interface has kind of a sender and a receiver.
And you usually write your interface blocks, you define your interface blocks from the perspective of the sender.
So if I look at my interface block, all these flow properties are coming out of the interface block.
That's the perspective of the sender.
And when I'm receiving the power in all my different subsystems, I have to switch the direction of the interface from sender to receiver.
And the way you switch that is by opening the port specification and checking the is conjugated box.
So we'll connect the first one here.
So this one's going in the right direction and all these are incorrect.
So I can click this port and interface it to there.
And I'm OK.
But if I do that, you see that my cameo tool gives me an error.
OK. And so if you haven't seen these errors, you can click on this little red X here and say it'll tell you it's an incompatible flow and it'll give you some possible suggestions.
So what I have to do is reverse the direction of this port power in.
And that just conjugated the ports.
If I open this one up now, now is conjugated is true.
So I can either go through and set is conjugated or I can kind of just wire them up like this.
And when I get rid of the red ink.
It'll conjugate all the ports.
So, again, I can do that and say reverse direction of the port power in.
And I'm pretty much good to go at this point.
And so this is one of those time consuming errors that happens all the time when you draw I.B.D.'s.
And the technique that I'm attempting to teach you here is to always define your interface blocks.
Before you start drawing I.B.D.'s and before you start putting item flows.
Oops. Something wrong on that one.
And it looks like I screwed it up a couple times.
Accidentally deleted my port.
And then finally to put the item flows on here I just take my flow property.
That's interesting.
Maybe I have to put a type.
Where do I want to go?
Interface blocks.
Signal.
So if you haven't seen item flow manager before.
Item flow manager is a very confusing user interface compared to most things in cameo.
But what you have to check when you put the item flow on there is that it's going in the right direction.
So I'm going from the power supply to the image processing subsystem.
And when I say finish it will put that on there.
Okay.
So the first thing that I did.
And I now realize remind myself why I had to have all those signals defined.
So when I tried to drop the flow property onto the connector.
And the flow property didn't have a type on it.
Cameo wouldn't let me do it.
So the first thing I did is I took the signal power distribution.
And I dropped it on this outflow property on iPower.
Okay.
And then the next thing that I did.
Was I took this flow property.
Power.
And I dropped it on my connector.
And I said set as item flow.
And I click finish.
And if I would have drawn these a little bit differently where this was off of that.
Then you can kind of see that it's putting the item flow on the right one.
Now I'll show you I'm going to make a mistake intentionally.
And show you what happens.
So I'm going to drop it on that connector.
But this time I'm going to change its direction to be backwards.
And as soon as I do that.
It should light up in red.
And now if I go here.
It's going to say.
Okay I see that one.
I just.
You edited the one of the interface.
You edited the iPower interface block.
That's what I think I'm missing.
Yeah so what I did.
When I created these flow properties they were untyped.
Okay.
And.
I typed it.
With the signal that we created on the signal diagram.
So the signal is called power distribution.
And I have a flow property called PWR.
Now it has a type on it called power distribution.
And once I put the type on it.
That's when cameo let me drop the item flow onto the diagram.
How did you type it?
I typed it by.
Here let me do another one.
So.
We have a signal that we made called power regulation.
Right.
And so how I typed it was I dropped the signal.
Onto the flow property.
And said change type.
And that's how.
All those types got on all those interface blocks.
And then once.
My flow property is tight.
Then I can put it on there.
Now how do I get rid of this.
Now we got to go look at the item flow manager.
So if you haven't used item flow manager.
It is.
Here.
And.
I've got this item flow that's basically wrong.
And one of the confusing things about this interface for item flow manager is that the delete button is kind of hiding up here.
OK.
So I want to delete my incorrect item flow.
Now I can close item flow manager.
And now I can go back and grab power.
Drop it on there.
And the direction is correct.
And I can finish it.
So if you've ever spent much time doing IVDs.
Your experience may be that this IVD.
And it got put together.
A lot more smoothly.
And with a lot less red ink.
Than what you've seen before.
If.
If you're already doing your.
Your IVDs and don't have any trouble with item flow manager.
Then I will say congratulations.
Your experience may not be typical.
But if you do them this way.
Where you define.
The flow properties and the signals and the interface blocks first.
Then getting your item flows on here.
Should just be a question of dragging the flow property.
Onto the connector.
And.
Checking the direction and it should work out.
Maybe smoother than what you've seen.
Before.
I hope so.
So my point is.
There is a sequence of steps that you can follow.
That will keep you out of trouble with item flow manager.
And personally for me the less I have to use item flow manager.
The happier I am because.
I find that it's.
User interface is not much fun.
I actually did these in exactly the wrong.
Order here so I'm going to reorder my diagram a little bit.
I think the cameo user interface is challenging everywhere.
Well.
It is challenging everywhere. Two of the most challenging places.
Are requirement numbering and item flow manager.
Having taught cameo for quite a while now.
Everybody gets stuck with item flow violations.
Everybody gets stuck with requirement numbering.
It's just kind of how it is.
But.
Really the only.
The only red ink I got here was trying to show you the mistakes that you're typically going to get.
I didn't get lots of other red ink.
And having completed this IBD.
This movie is something that personally I'm very happy about.
And the tricks are.
Define your interface blocks first to find your flow properties to find your signals.
And then do your IBDs where people get in trouble with IBDs.
Is very much just trying to add item flows like I can take this connector.
And I can go here and say new item flow.
And then pick something from somewhere.
And I'm going to get in huge trouble if I try to do it.
So I never make item flows by clicking here and using new item flow.
I always.
Check my directions on my ports carefully.
Check my directions on my flow properties carefully.
And then just drag the flow property onto the connector.
And it usually works pretty smoothly if you do it that way.
Now of course.
We cheated, right?
And how we cheated was that before we tried to draw this.
We asked AI.
Tell me the interfaces.
Show me the interface blocks.
Show me the flow properties on the interface blocks.
Make the signals which type those flow properties.
And I'm not going to make you go back and type all the flow properties on here for your lab.
But if you do it that way, define your interface blocks first.
Then define your flow properties.
Define your signals to type the flow properties.
Then making the IBD becomes much easier.
And you have a lot less red ink to fight.
So.
Let me snoop on you guys and see how you all did.
Or are doing.
So.
Yeah.
Look at that.
I see three IBDs and no red ink.
I'm very happy about that.
Because when I have taught this class, not this class, but taught other SysML classes before.
I always spend like half the lab debugging item flow violations.
So.
When I talk about writing a book on pain-free MBSE, there's going to be a whole section on what you just did.
Which is how to do all this and not get trapped in all the red ink.
You have to understand the relationship between a port and interface block.
A flow property.
And a signal.
And once you understand all that, you can do these IBDs without red ink.
Sound alright, everybody?
Okay.
It is 1213.
Seems like a good time for lunch to me.
Any objections?
So let's come back at 1.15.
And we'll continue going through logical architecture.
Is all this stuff making sense as I do it?
Because I didn't put lots of tutorial slides on here's what an IBD is and try to explain it that way.
I just sort of explained it in the lab.
All right.
Well, then we will reconvene in an hour.
And if any questions occur to you over the lunch break, save them up.
And we'll talk about them then.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Hello.
Everybody here?
Everybody's here in the meeting.
So, before we continue with logical architecture, which as you're seeing is a pretty big module
in this course, any questions about anything we did this morning?
That means it's all crystal clear, right?
I hope so, actually, because this is meant to be kind of a very simple, easy to follow,
straightforward process that steers you around the time and schedule of things.
All right.
So, just to kind of review really quickly, we crossed the boundary between conceptual modeling
and architecture when we started talking about subsystems.
And then, in addition to listing the subsystems, we started defining interfaces between subsystems.
Signals needed to type the flow properties on the interfaces and then IBDs to show those
signals crossing the interfaces.
Next, so we're still kind of working at the top level of the electron microscope
now.
And the next thing we want to do is a top level state machine that connects the subsystems.
And I basically got ChatGPT to describe this state machine with the prompt that
you see in orange, which says, describe the top level state machine that connects
all the subsystems of the SEM.
And ChatGPT told me what you see in white here.
It's going to initialize.
From initialization, it goes into idle.
Excuse me, are you sharing?
Oh, I'm very sorry.
Thank you for that.
Let me get that.
Apparently, I'm brain dead after lunch.
So let me go through that again while sharing the screen.
So we started by identifying all the subsystems.
Then we started identifying interfaces and defining interface blocks.
Those interface blocks have flow properties and the flow properties are typed by
signals.
And here are the signals.
And then once we put that structure in place with the interfaces being defined,
then it's much simpler to draw our IBDs and show the interfaces.
And I think where a lot of people get in trouble is that they try to make
those interfaces up as they're doing the IBDs instead of defining their
interfaces first.
And that causes a lot of trouble.
Next, what we're going to talk about is state machines.
And so I asked AI to give me the top level state machine that connects all
those subsystems.
And the response I got was we start out by initializing and that sets everything
up.
Then we go into idle.
And then we can transition into different operations from the idle state,
really different states from the idle state.
When we're scanning the image, we go into imaging.
After imaging, we go to image processing.
After image processing, we're going to analyze the images that are produced.
And after they're analyzed, we can generate reports.
And then we can go back to idle.
So I was particularly interested in both imaging and stage control because
later chapters in the book are going to do things with those two subsystems.
And so I asked it to describe substates within those two higher level states.
And I got this result.
And, you know, you can if you start looking at SysML version two language model,
you'll realize that the gap between what's being produced here and what's in a
SysML version two language model is really pretty small.
And it's just a question.
It's all the same information.
It's just a question of changing the format of it to basically generate this state machine in
SysML version two.
But we didn't have that available when I was writing the book.
And so manually, I basically constructed this state machine from what AI gave me.
And what we are now going to do is you're going to draw this state machine and then we're going to simulate it.
And just I'll give you a really, really quick review on state machine syntax and notation.
And is anybody new to state machines?
Anybody hasn't seen a state machine before or hasn't built one?
I have not.
OK.
So anybody else?
All right.
So the yellow bubbles on here or the round cornered rectangles that are in a column represent states of the system.
And what you can see, because we can have states within states, is that we can have hierarchical state machines with nesting in them.
And there's a bunch of different ways to do nested states.
I kind of kept it pretty simple in this example.
But the black dot or the black circles that you see are the initial state.
And you'll notice that when we're talking about substates, each substrate has an initial state.
And then the little bullseye, black and white bullseye looking state is the final state.
And so for our substates, we have both initial states and final states of the substrate.
When you hit the final state of a substate, like this one here, then what you do is you follow the unlabeled transition out of that substate.
OK.
And the transitions take you from state to state.
And what triggers a state transition is basically a signal.
So I'm going to guess that we have a signal called position stage.
Let me go back and look, actually, just to make sure.
So do we have a signal called position stage?
Yes, we do.
So right up here in the top center is the signal composition stage.
And when you draw a state machine, you can just drop that signal right on the transition so that, you know, and if you don't have the signal defined,
you can create new signals by just typing, basically draw the transition and without clicking anything, just type the name of the transition,
what you think is the name, but it's actually the single name and not the transition name.
What else?
So state machines get more complex than this.
You can put on any state what's called entry behavior, exit behavior and do behavior.
We're not going to do that on this particular state machine.
Any questions? All right.
So we're going to get ready to draw this state machine in cameo then.
And I will draw it with you.
So here we are on the desktop again, and I think this is my desktop, which it is.
So at this point, if you haven't used this, used cameo very much before, you can start to see that I'm getting to have a lot of tabs open.
And it sort of starts to get a little hard to follow, which is open.
And so there's kind of an easy thing you can do, which is to just close tabs.
So I closed all of them.
And now I'm just going to close some stuff up here, go back to my top level electron microscope diagram.
And what we want to do next is make a package in our logical model that I'm going to call top level state machine.
So I'm going to do this here.
Going to create a package.
I'm going to call it top level states state machine.
And now I'm going to create a diagram in my top level state machine, which is a sysml state machine diagram.
And you'll notice that when you create a state machine in sysml, it automatically gives you the initial state or the initial state and the first state that you transition into.
And I think I'm not going to bother using composite states.
I'm just going to make all these simple states.
I don't think I'll get in trouble by doing that.
I may be wrong, but I don't think I will.
I've heard that that can cause problems, but I've not fleshed out how that causes a problem.
Well, it might cause a problem when we're simulating, but I kind of don't think so.
So there's lots of different ways to do substates.
But I'm going to just start with just making everything a simple state, and we'll see if I get in trouble.
And I'm going to introduce you to the cameo simulator at this point as well.
So I'm just going to make another state here and a little bit bigger state over here.
And I'm going to put my state final over there.
And then we're going to do this top level composite state here.
And then we'll simulate it, and we'll see if we get in any trouble.
So we can label these.
This is initialization.
That's error.
And then we're going to wire these up with a couple transitions.
Now the question is, do I have a signal called initialization error?
If you haven't used the little magnifying glass here, so it looks like I don't.
When we did our signals before, we didn't make one for initialization error.
So let me show you how to do that.
So this search tool here is really useful, and that's this little search tool there.
So to label this transition initialization error, and you want to maybe watch this carefully,
I select the transition, and then without touching anything else, I type initialization error.
And what you can see over here in the containment tree is that it made a signal for me called initialization error.
So the quickest way to create signals in Cameo is actually to just label a transition.
So here's initialization error.
If I don't get the initialization error, I'm going to get initialization complete.
And I didn't notice that.
I'll just check again.
Do I have initialization complete?
No, I don't.
So I'm just going to select that and start typing initialization complete.
And then this state is called system ready.
It's easier to read.
And now I have a state called stage control.
And I think now we're going to get to a signal that we do have.
So I'm going to draw a transition from system ready into stage control.
And again, I'm going to check.
And here I have a signal called position stage.
So I'm going to take that signal and drop it on that transition.
So in all these cases, I want to point something out to you.
If I open this transition, the name of this transition is blank.
When I typed the name of that signal, it created a signal element called initialization error.
And then it created the trigger on the transition and said it's a type signal event and the signal is initialization error.
So I don't ever put anything in the name field on these transitions.
If you double click on it, like if you open the specification and type the signal name here, it's not going to work.
So just make sure you're clear about that.
The syntax on a state transition is you have trigger, guard, and effect.
The trigger is generally a signal.
It could be a different type of event.
So types of events that it could be are a change event or a time event.
But in this case, we want a signal event, and that's the most typical one.
The guard is a Boolean condition that gets specified here.
And then the effect is usually going to be an activity.
So what that means is that as this transition is firing, it can actually launch an activity that we've identified on an activity diagram.
All right.
So we're going to put three substates in here.
And then within this stage control state, we're going to put an initial and a final.
And then we're going to draw a transition back to system ready out of here.
And then we're going to connect these.
So technically speaking, this initial state is not really a state, but it is something called a pseudo state.
And the difference between a pseudo state and a regular state is that you can never rest in a pseudo state.
You always have to follow the transition out of it as soon as you enter it.
So my substates here are idle, moving, and stopping.
And again, if you remember our, let's just go back and look at the domain model to remind you what the stage is.
So we finally decided to call it sample stage instead of just stage.
But the stage sits inside the sample chamber and the sample sits on top of the stage.
And the stage is going to move back and forth because it has motors in it as an X motor and a Y motor.
We haven't specified those yet, but we will.
So you can call it sample stage or just call it stage.
But the stage is where we put our sample and then we move the stage underneath the electron beam.
So we have position stage coming in here.
Now we have move stage and we want to check if we have that signal already.
And we do not have that signal.
So we're going to create it.
And then we have another transition called position reached.
And we don't have that.
So the reason we don't have these signals yet is that when we asked for all the signals at the top level,
we didn't get the signals down inside the subsystems yet.
So this thing, position reached, is really a signal that's going to exist inside the stage subsystem.
Alright, so is everybody with me where I am on this diagram now?
Because the next thing I'm going to do is simulate it.
I got a yes from Mark.
Yep.
I haven't dropped my signals.
I'm building everything twice.
Okay.
Maybe when you build it twice, build it on the virtual machine first instead of on your local machine first.
Are you okay if I start simulating this now?
I'm good.
Okay.
Alright, so if you haven't used – well, first of all, is there anyone who has not used the Cameo simulator?
I have not.
Okay.
So this is going to be your introduction to the simulator.
Got it.
Alright.
So you should have this little triangle button up on the top of this little ribbon.
That is your simulator button.
So when you click it, you get this other window, and there's a lot of detail to be had in this simulation window.
And this isn't the only state machine we're going to do.
But a couple things you should know.
One is – somebody put something in the chat.
It says BRV.
You're right back.
Well, I'm going to hope that he knows how to use the simulator.
I think he probably does.
So one is you have a little – I'll date myself and say VCR control panel, more like a DVD control panel here.
And this little play button starts the simulator, and the little red square stops it.
The other thing that you'll find is that there's this thing called the trigger menu.
And what's on that trigger menu is all the signals that we are using on this state machine.
And we're going to give those signals to step through, stimulating the state machine.
Okay, so I'm going to – there's a bunch of other stuff here.
Console, variables, all kinds of stuff that we're not going to worry about right now.
But we're going to start this simulation.
And what you see is that when you start the simulator, it starts lighting things up.
And so this state that you see in red, that's not an error.
That's just where we are in the state machine right now.
So what signal do we want to give it?
We want to give it initialization complete and watch it go into the ready state.
So when I give it initialization complete, now I've advanced – excuse me, I've advanced to ready.
And next we want to go into stage control.
So I'm going to give it position stage.
And now what you see is that it's gone into the stage control state.
And it's dived in, dove in, drilled down into the internal details of this state.
And now we're looking at the substates.
So now we're in stage control, but our stage is idle.
We're going to move the stage.
And now the stage is moving.
And while the stage is moving, it's going to check if it's at its desired location or not.
And if it is, it's going to send back a signal that says the position has been reached.
In which case we stop, we get to the state final in the substate, and transition right back to the system ready state.
So that's your first quick introduction to the simulator.
Elena, how did you do? Did everything simulate okay?
That's great.
Good.
All right, so we're going to stop the simulation now and finish up the state machine.
And I'm not going to narrate this every step of the way.
I'm just going to draw it.
And then if you have questions, just shout out.
In this case, I have a signal called scan, and I'm going to use that instead of scan sample.
You want to be careful not to redundantly create some.
Yes.
If you go and you start just like naming that transition and that already and that signal already exists, it won't select it.
It will just create a redundant one.
I'm actually not positive.
You can try it.
What was the question again?
If you start typing scan here and there's already a scan sample, will it search for it, find it and pop it up?
I think you have to search first, but I'm not 100% positive.
I think it will create, if you don't already have something that is a scan, I think it automatically sets a new signal to scan.
Yeah, that's what I think too.
Sure, yes, it already exists, but I'm just asking if it doesn't already exist, but I'm asking if it does already exist.
It doesn't let you select the one that is not looking to see if something already exists and selects that.
I think you're correct, and it doesn't.
I think that due to naming conflicts, it might cause an issue because if you've already got something called scan and it's a signal,
you're trying to identify, you're trying to name another thing the exact same thing as a signal.
I think with signals, it might cause an issue.
It might grab the previous one you got created.
Yeah, I'm just not sure. You'll have to test it, Elena.
I'm not certain of the answer, and so the safe thing to do is test it.
But from a best practice standpoint, before you type a signal name, it's a good idea to search for it up here.
That's the way I've been doing it.
So I've got my top level states there.
I'm going to have one of those.
Sorry, sometimes I mumble to myself.
Probably very distracting.
Okay.
Daniel, you've got a hand up. Is that a question or you're done?
I'm done.
All right.
And it all simulates.
Oh, well, let's see.
Yep, all good.
Cool.
Okay.
And you can kind of see why I'm really looking forward to the day when I can just ask chat GPT to go create my state machine.
Because there's a fair amount of work involved in drawing these.
And it looks like I haven't put any signals on those.
So and you'll see when you simulate it, if you don't put any triggers on these transitions, the simulator will just zip right through them.
Without stopping.
Cool.
All right.
So I'm going to go simulate mine now.
First I'm going to save it.
Okay.
Okay.
So here's where all the years since I took high school grammar fail me.
So these aren't exactly nouns.
They're not things.
And they're not exactly verbs.
Okay.
And if you ask me what part of speech they are.
I'm going to be stumped for an answer.
Yeah.
Well, what they represent is they represent states that the system can be.
So it's either waiting for something or doing something and.
Yeah, I don't know that I would say that it's necessarily a verb of anything.
I mean, think about some of the most simple ones.
Just, you know, you could have a power on state.
You can have a power off state.
You can have a bit state.
You can have an initialization state.
So there's not one answer for that.
It's just going to be dependent on your system.
So I'm going to cheat and ask Google here on my phone.
Like what?
Grammatically, what part of what kind of element is the word analyze?
What part of speech is the word analyze?
It says it's a verb.
All right.
Let me try another one.
What part of speech is the word completed?
Part of speech is the word completed.
Completed is the past participle of the verb complete.
So it is considered a verb when used in a sentence.
So I guess they're kind of verbs.
You know, moving is a verb.
Stopping is a verb.
So, you know, but usually with state machines,
you don't really think so much about nouns and verbs.
They are states that the system can be.
But I guess most of the time, like ready, you know, what is ready?
I don't know.
So it's a good question.
And it's been way too many years since I took English in high school.
I apologize.
But let me check.
How's everybody doing with getting these state machines to simulate?
Lana, looks like you're still diagramming.
I am.
OK.
So we'll wait a minute or two and let you get that done and simulate it.
But I guess while you're doing that, I'll kind of go reinforce a little bit
what this approach is that I'm teaching you, the domain-driven logical
architecture approach.
And it's basically to do everything at the top level first,
going across the various subsystems.
And then when you get all that done the way you want it,
then you start diving down into each subsystem in turn.
And you kind of repeat the same process,
but it's within the subsystem instead of across the subsystem.
And, you know, in parallel with while you're doing this,
you're probably discovering new requirements,
and you're probably going to have subsystem level requirements as well as
the system level requirements.
So all the while that you're kind of modeling what the system does,
the basic approach is to get it right at the top level first.
And then you dive down to each subsystem in turn and get that right.
And, of course, if you're working on a team,
once you get the top level stuff correct,
then you can task different people on the team with going down into each subsystem.
Right.
So, does that all make sense just from a philosophical standpoint?
Yeah.
And another beautiful thing is it's just a few boxes and lines,
but it's so good at making clear when things happen at certain times,
but just in the space.
You know, imaging only happens after system ready.
And these are the three things.
Yeah, me too.
They're really powerful.
Yeah, in fact, that may be.
Not yet.
We still got some more to go, but you can.
And this is a really cool thing, which you may want to try.
Is just save that state machine as an image.
Go drop it onto Chad GPT and say, write me the C++ code or microcontroller
and watch it go, because it's really cool.
In fact, this was the diagram I was working with Brian on a Zoom call.
And I had done this state machine, which, you know, doing it the first time
took a little bit of work to transcribe what Chad GPT did.
Once you see the answer, it's pretty quick to draw it.
But it took a little while to get this, you know, to simulate correctly
based on what AI gave me.
But then from there, when you just say, write the code for this,
boom, done.
You know, I just started playing with Chad GPT as of, you know, yesterday and today.
And I just tried playing around with it after I saw you generate some images.
And I tried to generate an image and I don't know, I kept running into an error
or something because I asked it to generate an image, you know, for my family vacation,
which is, you know, me and my wife and three daughters.
We've been ready to go to Columbia.
I was like, hey, show me an image of, you know, a man, a woman and their three daughters.
And for some reason, I don't know if it's some kind of politically correct thing or something.
It kept sticking a little boy in there.
And I'm like, please replace the little boy with a little girl.
And it said, yes, this is this.
And it could not get rid of the little boy.
I'm like, like, it would add a little boy or something and then add a little girl.
I don't know if that's like a common thing or that's just me.
Well, that's called an A.I. hallucination.
And they do happen fairly frequently.
They happen a little more frequently with image generation because with A.I.
there's actually like a creativity setting.
And when it's trying to be creative, it has more latitude to change things.
But there is a whole political correct wokeness about chat GPT.
And this is going to vary from different A.I. models.
You know, Grok is less woke than chat GPT is.
It has to do a lot with, you know, who owns the company that built the A.I. package.
I tried so many times to get it to just remove the little boy.
And it would not do it.
And I'm just like, I don't have a little boy.
I would love to have one with a little image, you know, just like that.
I told it the first time.
I was like, oh, it's perfect.
I'm like, that's a perfect image.
I love it.
It's in the place where I'm going.
It's actually like an image of like the amusement park we're going down there.
And I was like, just please replace the little boy in the image with a little girl.
And it won't do it.
Yeah, I understand.
I actually made a video.
It's up on YouTube called multimodal hallucinations.
And I don't know if you guys follow baseball, but I live in Los Angeles.
And we have a kind of a superhuman ballplayer, Shohei Otani.
And I noticed last summer watching a Dodger game that Shohei holds his bat kind of like a samurai holds his sword, like kind of up like this, straight up and down.
And so I had to start generating images of Shohei and of a samurai.
And I tried to get the samurai and Shohei like the samurai standing behind Shohei in the same batting stance.
Shohei bats left handed.
And it kind of just started refusing.
It would always make the samurai in a right handed stance and not a left handed stance.
There was nothing I could do to stop it.
It was I made a whole video about it.
Why do you think that was?
Well, OK, at the next break, I'll go find my video and then I'll show it to you after the break.
But it basically got very confused between left handed and right handed.
It just like totally confused those concepts.
How are we doing, Elena? Are you done with your state machine? Does it simulate?
I'm done.
Cool. All right.
So we're going to move on then.
So this particular slide deck has a lot of stuff in it.
There's like five or six different labs all rolled into logical architecture.
But architecture is complicated.
So that's that's why it's like that is because architecture is it's complex and difficult.
All right. So now what we're going to try to do is illustrate this recursive subsystem decomposition,
which means we start taking the subsystems subsystems apart one at a time.
And then then kind of becomes lather, rinse and repeat.
You just do it once at the top level and then you do it at as many levels as you need to to get down.
And what we're not doing just to be clear is what we're not doing is starting with one top level function and decomposing it into sub functions and sub sub functions.
OK, that's just not in this process that I'm teaching you.
And so it goes back to the stop banging your head against the wall if it hurts when you do it right philosophy.
So what we're going to do now is we're going to go decompose the stage subsystem and we're going to go make this BDD.
And so if you guys are ready, we're going to do that in the lab. Does anybody need a break before?
I would say let's get this BDD done and then take a break.
But if you guys need a break, let me know.
And we can take one now. All right. Not hearing any requests for breaks.
Off we go.
Into detailed BDD labs.
Save my model here.
Close up a couple of tabs.
And now inside subsystems.
What we're going to do is go into the domain model.
Excuse me.
I want to go into subsystems.
And I want to look at the sample stage subsystem.
And what we're going to do now is we're going to make a child BDD right inside of this subsystem.
So I'm going to click on the block sample stage subsystem.
And I'm just going to go create a diagram in here, which is a BDD.
And then I always count how many of them I have to make.
Hey Doug, have you ever tried typing them all out and then piecing them in there that way it kills two birds with one stone?
Because then you just type it once and you paste it and it automatically creates another block.
So you don't have to do all the clicking and rename and click and rename.
Well, let's try this. I think I could probably just type it in a note, right?
And then just copy and paste it from the note.
So let's try this your way.
I always learn what I'm teaching, so I'm happy to learn a new trick here.
So I'm going to just start typing the names of these.
I may never teach the same again after this.
All right, so here they are all typed in in a note.
And I'm going to copy them.
I can't use my keyboard to do copy, but I'll do that.
And then if I click on the diagram, I can say paste.
Sorry, it's a pain when your keyboard doesn't work.
I actually can't delete that thing now.
Do you have like a notepad?
It's not in the containment tree.
So I've selected the...
Every time I do that, it selects the whole note.
You can just copy the text, paste it onto a sticky note on your computer or Word doc or notepad, and then just paste it back in.
Let me see if I just...
I've got one note open, so I've got all the images there.
So I just type out all the text there right next to the image, and then I just paste it in.
So I'm copying it.
Let me see if I can find...
Oops, notepad here.
I'm a Mac guy, so...
If I use OneNote, that would work fine.
Did you open up OneNote for Windows there?
OneNote for Windows 10.
That's what I use.
Oh, but I don't have a...
I don't have a Windows account.
Click on the Windows button and then type in Word.
If you just click on the button, then you start typing Word.
Yeah, Wordpad.
Then Control-V there.
Alright, I assume I have to...
I would say... I've not tried it like that, but yeah, usually I put it as a list. Yeah, just like that.
This would probably be faster if my keyboard worked.
Alright, so...
No, I'm on a Mac keyboard, and it's a Windows virtual machine.
That's the problem, right, is that...
Alright, so I've copied these.
And now what you're saying is if I go here...
Just click there on the diagram.
Just click on the diagram, and then there you go, Elements.
Then Block.
That's it.
Well, that's pretty cool, actually.
You can do the same thing with any of the properties of the block.
I just usually type out all the properties, and I paste them on the Containment Tree.
On the block itself.
Well...
Yeah, you can just click and say Control-V if you're on a PC, but on mine...
Yeah, that's cool.
So I've got X-Motor, Y-Motor.
X-Position Sensor.
So...
Yeah, it's funny because I literally can't...
Well, maybe I can.
Now I got rid of them.
Yeah, not being able to use your control keys is kind of...
A little bit frustrating, so I appreciate your bearing with me.
I actually don't need Stage 5.
Oh, there it is.
Okay.
Okay.
So, one thing that I just did is I converted my Move algorithm from a block into an activity.
And I'll show you in a few minutes why I did that.
Okay.
So basically now instead of having done a bunch of nested activity diagrams to figure out what my functions are, I'm just going to add the operations to the blocks.
And how you do that is you click this little button here and say Operation.
Just say Control-Stage.
And...
So what you're doing is you're still uncovering all of your functions, but you're just putting the functions on the parts.
And I can add values here as well.
If it's a real, I can type that it's a real right in that string.
So we don't miss any of the functions by doing it this way.
It's just, at least to me, a lot more efficient than drawing all those trees of activities.
I just find this to be...
I'm not sure if you know, Doug, or if you've ever used that wizard, but you can actually generate a BDD with activities in the form of a block.
It just happens to be a separate activity.
Have you used that feature?
I have not.
When I'm done drawing, I'm going to ask you to explain it to me.
Okay, yeah, I'm not a master at it. I've used it a couple times.
I can't listen and draw at the same time.
It's like walking and chewing gum, you know.
Man's got to know his limitations.
That's what Clint Eastwood said.
What movie was that? Dirty Harry?
Probably Dirty Harry, yeah.
Man's got to know his limitations.
But I'm always happy to learn new features of Cameo. I pass them on to the next group of students that I teach.
Just an endless amount of features in Cameo.
Totally.
The only way I know how to do it is teach the ones that I use and don't teach the ones that I don't use.
But I will let you give me a demo of that in a minute.
Sure.
The values you're just adding, the type of value it should be, you can just type it in there.
Yeah, it should.
Let's take a look at this one when I do it.
I believe if I open this value up, it's going to give me the name and you see it filled in the type of Boolean.
From after the colon it takes it as a type.
Okay, got it.
Now, this one is kind of an interesting communication interface because it has a signal reception on it.
And so to add my signal reception, if I go find my signal, assuming I have one.
No, I actually don't.
Never mind.
Because if I had a signal, I could just drop it on there.
All right, I think I'm done drawing.
Okay.
So again, it's a subjective opinion, but I find it a lot faster to work this way than by using activity diagrams and object flows and pins and activity parameters.
I think this to me is just kind of one step and I find it simpler.
All right, do you want to show me what you are talking about here?
So let me try to remember how to just open your screen.
I double click this.
Maybe I need to.                

on 2024-12-16

language: EN

                  WEBVTT
Alright, looks like everybody's either with me or close, so I'm going to go back here
and now I'm going to make the requirements table in that package.
So that is create diagram requirements table.
And now for the scope, I'm just going to drop my requirements package on the scope.
And you see that they're here.
And now I can just type the text in, I can type it in either on the diagram or in here.
But if I go back to my requirements diagram, that should be populated.
So there is a way where you can go directly from chat GPT and paste into either Word or Excel into a CSV.
And there is a capability for CSV import or copy and paste.
But I'm probably going to leave that to your own devices, unless you want me to poke at it a little more.
I will show you one other thing about the requirements numbering.
So again, to get back into that numbering dialog, I click these three little dots.
Couple things you should know about this numbering.
One is it's really easy to get gaps in your numbering sequence.
So I can, for example, increase that number or decrease it.
But in practice, what often happens is that, you know, you add some, you delete some, and they're not numbered the way you want, and you get gaps in the numbering.
So there's two important things to know about the numbering in here.
One is that this information about the prefix and the separator works on a package by package basis.
So if you want different numbering on one set of requirements than in another, you basically sub package them here.
And the other is there's a really useful feature in Cameo for resolving gaps in the numbering.
But it's hidden very carefully.
So watch closely now.
Do you see there's this little button called details?
If I click that details button, it unlocks a bunch of hidden functionality.
And if you get to where you have, you know, your numbering is going one, two, three, four, six, seven, eight, and I guess I can create that condition and then show you this.
So let's suppose I delete this requirement five.
And you don't necessarily have to follow me here, but you want to at least watch me.
So I deleted requirement five.
And then I'm going to create three more.
Requirement six.
Requirement seven.
Requirement eight.
And I'm going to re-enter the name real-time display here.
Then I'm going to go back and delete six and delete seven.
Then I'm going to go back into my requirements numbering.
Which I have to get into this way.
And now I have a problem one, two, three, four, eight.
Well, I can decrease eight.
It'll go to seven.
And I can do that a whole bunch of times.
But a lot of times you're going to get to where like the numbering is just messed up.
And what you want to do is use this function called renumber recursively.
And that will remove gaps in your numbering scheme.
The other thing I can show you about requirements in Cameo is if I use a containment relationship.
So let's suppose I decide that real-time display is actually something that belongs to user interface.
So I can use containment, which shows up here, and I can make real-time display be part of my user interface.
So I'm going to show you another useful trick in Cameo.
You may want to follow me on this part.
So first of all, if I just pick containment off here.
So in this case, when I'm drawing it top down, it's the correct direction on the containment.
But a useful feature to know, and that actually doesn't work on my keyboard because I'm on a Mac keyboard, but the control key will reverse the direction of that.
If you do it while you're drawing it.
So now you notice when I did this, it changed my requirement number from 8 to be 3.1, which in most cases is kind of what you want it to do, right?
So when I say that this requirement is contained within that requirement, it'll actually renumber it.
If I look at my table now, what you see is that 3 now has this little plus sign underneath it, and I can expand that to see 3.1.
So those are just useful things to know about working with requirements in Cameo.
I can now. Yeah, you're a little bit faint, but I can hear you.
So you said the control key will reverse the direction while you're drawing the relation on there.
I think it's a control key. It's either option or control or one of those.
Okay, control just has a pivot point for me.
Yeah, it might be the option key.
It might be the.
You know, unfortunately, this working on a Mac and having a PC keyboard in here, it looks like it's the key.
Yeah, and I don't have an alt key on my Mac keyboard.
That's why.
So, yeah, you can.
And there's two kinds of containment.
Like if you try and drive from here, from the little quick link menu, there is generally a containment that way.
And there's also usually a second one that goes in the other direction.
In fact, usually when I work with it, there's a little menu here.
Maybe they kind of.
So we're running twenty twenty four instead of what I usually run, which is twenty twenty two.
And maybe they finally decided that's really confusing having two containment and they just switched it.
So just as well, because this one is the one that you usually want, as you usually want to draw them top down.
And none of my keys are.
Working for that.
So I kind of left that lab to be a little bit free form.
But I think if you done this and made a table.
And you see how the table works.
Oh, I should also show you about the columns field.
In the in the table, this field here called columns.
Let's you add or remove columns from the table.
So if I want to put like satisfied by in here.
Now I've got another column here.
So you can use columns to control.
These are these are kind of all the fields that you have built in to to your requirements element.
And so you can also create new columns and do things like that.
But but as a quick intro to the requirements editor.
That's probably sufficient.
One thing that you want to be aware of, see if I can manage to do this.
If I shrink my cameo window.
If you shrink this window horizontally.
This little columns tab will disappear to save space.
And it'll be replaced by like two little carrots.
And you have to know that to.
To find that table.
So something to be aware of.
Anything else you would like me to tell you about requirements.
Otherwise, I'm about ready to move on to talking about use cases.
And if there's anything else that you would like me to.
To tell you about requirements.
I am happy to do it seems to let me.
Stretch my window down, but not.
Not horizontally.
Maybe if I do it this way.
That's probably just a feature of the amazing Mac book stuff.
Yeah, I mean, their their virtual PC environment seems to work pretty well.
So I have.
I have no complaints about it so far.
It's been working.
Really pretty well, I think.
All right.
Anything else you would like to discuss with.
With requirements here.
Yeah, mostly that chapter is about.
How to use AI to.
To discover the requirements.
Yeah, that's probably the fastest way to.
To get them in there.
I think you have to get it into a.
A CSV kind of.
Representation like out of Excel or out of word.
And then I've seen them paste in after you do that.
So you sort of have to go from.
Chat GPT into kind of a comma separated file.
And then.
From there into.
The cameo.
And you probably have to match the number of columns.
In your requirements table.
To the number of columns that you have in.
In your table out of chat.
Okay.
Does anybody need another break before we go into these cases?
Are you guys good?
Okay.
All right.
So.
If anybody, if no one has objections, I'm going to go into our next.
Slide deck here, which is on.
Use case model.
So.
Sort of slide zero in this slide deck.
Is that if you just ask.
AI to tell you about use cases.
You might get.
Business use cases.
Okay.
So when I just said, give me the use cases for an electron microscope.
It told me all the ways that you could use an electron.
And.
That wasn't what I want.
What I wanted.
So I asked it to tell me about software system use cases.
And you'll notice now.
It's giving me software slash system.
For our electron microscope and.
When you write use cases, they really should be verb phrases or when you name use cases.
They should be verb phrases.
So what goes on your domain model are nouns.
Things.
What goes on your use case diagram are verb phrases.
And what goes in your requirements are shelf statements.
And so.
We'll come back and draw this diagram in a little bit.
In cameo, but.
Here's the top level use cases that AI gave me for.
Operating.
Our electron microscope.
And as I said, we'll.
I'm going to go through the PowerPoint and then we'll do this as a lab.
At the end of the lecture.
And then that'll be about as far as we go for today is to.
To get through use cases.
We've got.
12 slide decks to get to in three days and this is slide deck number five already.
So we're just fine in terms of.
Time and coverage.
And.
So you'll see that some of these use cases are for.
Hardware related things like moving the stage around.
And adjusting the beam parameters.
Easily using the operator control interface.
And then some of these use cases relate to image processing.
Which is more the.
The user of the electron microscope from a.
Science standpoint, right?
Someone who wants to actually.
Look at an image and do something with it.
So there's kind of two sets of use cases in here.
And then actually a third set.
Which is to.
Calibrate the system and make sure everything is working right.
So there's admin stuff.
To update the software, manage users, things like that, right?
So these are the scenarios of the system being.
Operated.
So this is one of the first things I tried with chat.
Gbt was I tried to just.
Ask it to write the narrative for a use case.
And I was kind of stunned.
Because.
My reaction was like, holy crap, this thing writes use cases.
Really fast and at an amazing level of detail.
And if you've ever tried to get systems engineers to write use cases.
It's like pulling teeth.
Okay, it's.
Systems engineers.
Basically don't like to do this.
And.
One of the reasons they don't like to do it is it's kind of a lot of work, right?
It's real work to actually.
Write this.
Write all this stuff then.
And so by default, what chat Gbt will use.
Is a very long and verbose use case template.
That was originally proposed by a guy named Alastair Coburn in his book about use cases.
And he calls these fully dressed use cases.
And one of the reasons that people like this template is because.
It has sections in it for preconditions.
And post conditions.
And it seems very complete.
Okay.
Well, I never liked this template myself because it's too much work.
And.
When I started asking AI to write the use cases.
It was kind of like, wow, this isn't really a lot of work anymore because AI will just spit this out.
But I decided I still don't like this.
Kind of.
Big huge template.
Because it's actually a lot of work to read the use case descriptions when they're written in this template.
And I can tell you from some 20 or 30 years of teaching people how to write use cases.
That what people typically do with this.
Long template is they kind of.
Skip the most important part, which is.
The sunny day scenario and the rainy day scenario.
Okay.
Well, I didn't skip it because.
The sunny day scenario here is my main success scenario.
And.
Here's my extensions.
Here's my alternate flows.
So it kind of covers all the detail.
But it's still a lot of work to read it.
And so.
I sort of.
Poke a little fun in my book at what.
Alastair Kovar and calls a fully dressed use case template.
And I raised the question about whether.
This guy is fully dressed or if he's overdressed.
And.
If he's walking on Waikiki Beach in his snow shoes and parka.
Then he might be overdressed.
Although.
If you believe that the ice age is coming, then he might be fully.
So fully dressed or overdressed is kind of a subjective question.
And one of the cool things about AI is I can say, make me a picture of a guy.
In snow shoes walking on a frigid Waikiki Beach and it'll do it.
So I had a little fun doing that.
But I like a shorter, more concise use case template.
And so.
I wrote, I had it rewrite the use case template after.
Reading my books about use cases, then I said, I want you to use the template.
That I used in my book and told it what page.
And now it writes the use case in a.
Shorter, less verbose style.
And one of the things that I noticed, which I found was really interesting and curious.
Is you notice there's seven steps.
In the sunny day scenario of this use case.
I guess this is a different use case.
So, but there's 14 steps in it.
What I noticed is when I asked it to write the use case.
In a shorter template.
It omitted about half the steps.
And.
What it was doing before was it was.
Specifying a bunch of kind of internal details like I don't know if you can read this.
But in step number eight here, it says.
The software communicates the focus settings to the instrument.
That's kind of internal detail within the use case.
That you can really leave out of the use case description.
So.
I continue to like the use cases better.
Using a less verbose style.
And one of the things that I noticed here.
When this use case came out.
Came out of chat GPT.
Was that there was no exception behavior in this use case.
And having taught use cases for many, many years.
That's always a red flag for me when I see no exception behavior.
So.
In fact, what it did.
Is.
It kind of misnamed my exception behavior to be alternate behavior.
But you always want to be suspicious.
Of a use case that.
Has no exception behavior in it.
So basically, I will write the use case narratives in any style that you like.
And you can pick the style that works for you.
You're taking the class for me, so I get to inflict my opinion on you about what I like.
But.
I think a use case written at this level of detail is much more readable.
Than.
The big verbose one.
And what typically gets done on most projects.
Is because people hate writing use cases.
They just get it. They skip writing the narrative English version.
And they go directly from the use case diagram.
To usually activity diagrams.
So you can elaborate a use case on.
Either an activity diagram or a sequence diagram.
But usually it's done on activity diagrams.
And if you follow magic grid, they will tell you to start doing functional analysis.
Immediately underneath these cases, so they basically treat.
The use cases as high level functions of the system.
And then start drawing activity diagrams and decomposing activities into child diagrams.
Sub sub diagrams.
And in my experience, that's where you start spending a lot of your modeling time on activity diagrams.
So if you have experienced.
And I think at least one of you said, yep, we got this problem.
Where the activity diagrams take up all your modeling time.
It's probably because they are treating your use cases as.
System functions.
And not actual proper use cases and then using those.
I level system functions to do functional decomposition.
And so we're kind of in philosophy land here.
But I think it's worth talking about.
What's the difference?
Because a lot of people don't understand.
What is the difference between a functional decomposition and a scenario decomposition?
And so what a use case model is supposed to be.
Is a scenario decomposition where you're talking about.
The system from the perspective of the user.
As opposed to a functional decomposition.
Where you're talking about the system from the perspective of the system.
And what its functions are.
Everybody clear on that, because I think it's a really important.
Distinction.
So when you.
Attack use cases.
From the user perspective.
Then what you focus on is.
What actions can the user take.
That are different from that main.
Basic typical usage.
Sunny day scenario.
That's your alternate behaviors.
And then what errors can happen, what exceptions can happen.
During that use case.
And it's really identifying the alternate and exception behaviors from the use case.
That kind of.
Set it apart from a functional decomposition.
If I pop back to my.
Requirements lecture here for a minute.
Remember we were talking about zigzagging to use cases.
And focusing on alternate and exception behavior.
And.
That was this chart here.
Where we identified all the alternate and exception behavior requirements.
Okay.
So if you go straight to a functional decomposition.
And you don't use your use cases.
To identify this alternate and exception behavior.
Then what happens is in your requirements model.
You don't have the requirements for the alternate exception behavior.
Of these cases.
And so there are big advantages to, at least in my mind.
There's big advantages to actually using the use cases properly.
Any questions on this?
I tend to get up on my soap box about it.
But I do think it's really important.
So.
Whereas the typical.
Usage of activity diagrams in SysML.
Is to decompose functions.
What I like to use activity diagrams for in SysML.
Is to detail out the alternate and exception behaviors.
So it's a.
It's a difference in usage.
You know it's still a yellow use case bubble with an activity diagram inside it.
But what's on that activity diagram is going to be a little different.
Depending on whether you're treating your use case as a system function.
Or whether you're treating your use case as a scenario.
So I'm not hearing any comments.
I don't know.
I don't know what you're thinking about this lecture.
But I'm just going to continue with it.
You can tell me after the lecture what you thought about it.
Or you can interrupt me at any point.
So.
And I kind of mentioned this during the requirements chapter.
Is when you're putting your requirements together.
You don't want the requirements to be all full of holes.
It's.
It causes a lot of trouble if your requirements.
Are incomplete.
And if you don't analyze the sunny day and rainy day.
Behavior in your use cases.
Then you're going to get Swiss cheese requirements.
So you're really not done if you haven't considered the rainy day scenarios.
Mark, you're going to say something.
Oh, sorry.
That activity diagram was interesting.
I have not seen that before.
The structured branching.
To have.
Yeah.
So I actually there's a feature in cameo.
That no one ever talks about and no one ever uses because the feature itself.
Is buddy.
I'm going to show it to you and then I'll suggest that you don't use it to draw your activity diagrams.
But it actually generates them this way.
So.
If you don't write your use cases to consider.
Alternate and exception behavior.
You're going to miss all these requirements.
And you can try this prompting yourself.
But or you can take my word for it.
You miss a lot of stuff.
If you don't consider your rainy day scenarios.
You can also.
Do your activity diagrams and put requirements on them.
And then you can say.
You know.
If the position of my stage.
Is not correct.
I have to adjust that stage position.
And I have a requirement here that says.
I need the ability to reposition the stage.
And I can say that this thing.
Refines that requirement.
So you don't always have to put.
The requirements on the activity diagrams but you certainly can if you want to verify.
That you're covering all.
You know everything that you need to cover.
You can also elaborate your use case.
With a sequence diagram instead of an activity diagram.
And.
If you do that in an object oriented design approach.
It will help you link your functions to your box your operations.
And I'll show you later when we get into.
Sequence diagram lecture.
How to do this.
But how I what I like to do is I like to use.
The activity diagrams to.
Make sure I've identified my alternate and exception behavior.
And then I like to use sequence diagrams.
To actually put that behavior on the appropriate blocks.
So here's a template.
That I like to use.
And.
Remember when I trained my agent Obi Wan.
This is one of the books that I had him read.
And then later.
I found the page number in that book and I said.
See how the use case is written in this book.
On page 270 whatever.
I want you to always write your use cases that way.
And AI learns.
Very quickly.
And so now.
In Obi Wan's training he knows.
That whenever I ask him to write a use case narrative he's going to write it in this format.
And just to understand what the format is.
To a is an alternate of step two.
After I finish to a.
It rejoins at step three.
For he is an alternate of step four.
And when it's resolved it rejoins.
Back at step four and tries it again.
So this format allows you to basically.
Generate an activity diagram for your test team to use.
Where they can step through all the branches of the use case.
And test the system behavior.
And you can do something as simple if you're training chat GPT.
Yourself you can create a custom GPT file.
Take a screenshot of this PowerPoint slide.
You know screenshot of the.
The little white block with the format in it.
And say I want you to use a template like this when you write a use case.
And pretty much it will do it.
Okay so you can.
You can teach it and you don't have to use my template you can make a template.
You know for your own maybe you like to always.
Show the preconditions and post conditions.
But you can basically train AI to write use cases.
In the style that you want them and that's really pretty cool having.
Having trained some thousands of people and how to write use cases.
It's a lot faster to train app.
Just like say do it like this.
And it'll figure it out and follow it.
It'll just write it in there.
So AI is really cool for writing use cases.
And the number one objection that people have to writing use cases.
Is that it takes too freaking long.
And it doesn't with AI.
It'll write them very quickly.
Now you still have to check it.
But.
You know it is a lot faster than starting from scratch.
So another thing that you can do with.
It's not exactly part of use case modeling technically.
But it kind of goes hand in glove with use case modeling.
Is you can start asking it to identify all the screens of your system.
And it'll be just like show me the screens for image processing.
And it'll tell you you know exactly what screens you need.
What each one of them is for.
What kind of UI widgets you want on it if you want to do that.
But it'll tell you what screens to build.
And it will make you wire frames or storyboards of those screens.
If you just ask it to generate a wire frame using HTML, jQuery, mobile and CSS.
Because AI generates HTML very well.
And jQuery mobile has been around long enough that AI understands how to generate webpages with jQuery and HTML.
So.
When you're modeling your use cases, especially if they're software use cases.
It's really useful to let AI mock up your screens.
And then you can check what's on this screen.
Like what buttons are on here.
And what menu options are on the screen.
All your user interface widgets.
You can check that against the use case narrative.
And make sure that that's working the way you want it.
So that's going to bring us to the last lab of the day.
And that lab is going to be to start with to draw this use case diagram.
So I'm going to go back over to Cameo and start doing that.
And here's how we're going to do it.
Use case diagram in the PowerPoint somewhere.
Yeah, it is.
That slide.
Slide four of 18.
Okay.
Got it.
Thank you.
So here's how we're going to make this.
We're going to, and actually Maria had a good idea, which is make sure your model is saved at this point.
So hit the little floppy disk icon there.
And then we'll save it again after this lab.
So when we come back tomorrow, you'll have your conceptual model done pretty much.
So we're going to create a new package in here.
And we're going to call it use cases.
And you'll notice, by the way, that my package structure is starting to fill up here.
So now we're going to go make a use case diagram inside of that package.
That's a SysML use case diagram.
And then I'm going to count for you so you don't have to.
We have five, ten.
I got like 14 bubbles on there.
So clearly this is a job for the sticky button.
There is an alternative that's potentially faster.
If you were to, if you had all those typed out, so it might be easier to type them out into a text file or Excel file or something like that.
You can just copy and paste them in as use cases.
That way you don't have to paste them in and then type them in.
I'm sure you're right, but I don't have them all typed out.
And I want to show you how to write them anyway, which is something that most SysML training courses don't even bother to do is teach you how to actually write a use case, which, of course, bugs me no end.
So now I've got my diagram kind of laid out here, and most of the time I'm just going to use regular associations to connect these guys.
So we might as well start naming things.
This is my operator.
That is control instrument.
This is process and analyze images.
And there are a couple of other relationships that are the standard ones to use on use case diagrams.
One is called include and the other is called extend.
This diagram doesn't have any extends on it, but I'll probably show you how to use it anyway.
Extends is one of the most confusing elements of use case modeling.
Also, I don't know how much I've shown you the layout techniques, but if I haven't showed them to you, I can show them to you now.
So on this layout menu item, I have an option to center all these vertically.
And it's actually quite amazing, but neatness really does count in your SysML models.
So it's a good idea to get into the habit of using those layout tools.
So now I'm going to use include relationships between my top level use cases and the ones on this side.
And I'm going to have a whole bunch of includes and I'll explain to you what includes means in a minute.
But I'm going to use my sticky button and draw these includes.
One of the things that I hope comes out of this class is that
you kind of come away with a feeling of how to be pretty efficient in drawing with Cameo.
So it is perhaps a big enough exercise to do that.
I got to go back and use regular associations for these two.
So that's getting close to the end of the day.
I'm getting a little punchy here, but we'll be done in a few minutes.
So we can manipulate the stage.
We can select an imaging mode.
So by using includes, what we're basically saying is that these use cases are kind of part of this use case.
Okay.
Okay.
I had one I had one extra one.
Okay.
Let me go spy on you guys a little bit and see
how you're all doing.
Looks like you're doing good.
We'll give you a minute and then I'm going to show you how to use extends.
Okay.
Okay.
Okay.
All right.
So I'm going to assume that you're either done or close enough to done to let me introduce something new here.
So we kind of already introduced includes and that just means that these are parts of the higher level use case basically.
The reason includes got the reason includes exist is mostly for reusing a scenario that's going to appear in multiple use cases.
So that didn't happen in this case, but we can still use includes to do it.
Extends tends to be a very confusing construct in in modeling use cases, but it's normally used for exception handling.
And the best way I can give you to think about it is suppose I'm trying to store data here and my storage is full.
Okay.
Or maybe I'm trying to retrieve data and my connection is down.
Okay.
So those are two different ways that this use case might need to be extended.
So I'm going to use extends and show you how to model that.
So first of all, I'm going to make two use cases here.
And I'm going to call them.
Handle full storage.
And recover from lost connection.
So when you use extends, there's a concept called extension points.
And it means that when you're writing this use case, you have to handle there.
There's a point where this use case might get extended with whatever's in here, and it's not in your normal behavior.
Sunny day scenario, but it's something that's going to require handling.
So when you draw the extends, you generally draw it in the backwards direction from the includes.
So let's see if I do this right. If I start this from here, I'm going to draw the arrow this way.
So I start from the child and I draw to the parent.
Once I click, it says, hey, there's no extension point here.
Do I want to add one? And I'm going to say yes.
And the extension point is storage is.
And so the way you read this is that.
When I'm executing this use case, if I run into the condition.
That my storage is full.
Then I'm going to go jump into this extended use case for full for handling.
So I'm going to do it once more.
Just so you've seen it twice and you can try it.
So now I'm going to recover from a lost connection.
So I'm going to take my extends arrow.
Started here.
Jot there.
And in this case, it's not the same extension point.
So I have to create a new one.
And this is connection lost.
And now my use case has two extension points in it.
One for when the storage is full.
And the other for when my connection is lost.
And then how I handle that error condition is going to be described in here.
I can't quite see if you guys have done that already.
Okay.
So this is going to be the last thing that we do today.
Okay, I think in the slides we've kind of written out the detail for this acquire images use case.
And so I want to show you how you can go and specify that.
You guys all done with extends at this point?
Yeah.
Okay.
So let's go do acquire images.
Okay.
So now we get a bunch of options.
So I've opened up the use case spec.
And probably what you're going to wind up doing is just typing the use case in here in this documentation field.
But I do want to show you this other feature.
And then I'm going to recommend that you don't really use it very much or you don't use all of it.
And I'll kind of show you how to use it and then tell you that unfortunately the tool is buggy.
And, you know, if you use this this feature, it's kind of at your own risk and I don't recommend it.
But I'm going to open up this thing called the use case scenario sketch.
And the reason it's worth showing you is that this is actually the right idea about how to specify use cases.
Unfortunately, their implementation is pretty flawed.
But I'm going to show you how to do it anyway.
Because I'd rather you know how to think about writing a use case.
And then once you understand how to think about it, you can just go back and write it in here.
Yeah.
I have not heard, but this is my first time using 2024 so we can find out.
I, I suspect it hasn't because.
Actually met like the so project manager for cameo.
Over at that and cozy conference in Hawaii about a year and a half ago.
And I kind of leaned on him a little bit saying, hey, this feature is almost really great.
Can you fix it?
And he was sort of like, man, nobody writes use cases anyway.
We don't want to bother.
We got more important stuff to do.
So I don't really expect it to be fixed, but we'll try it and see.
And so now what we're going to do and again, I'm working kind of from from here.
I wonder if I can leave this on the screen.
Maybe I can leave it on the screen.
Well, at least if I do it this way, I can just pop back and forth.
So I want these seven steps in my basic course, right?
And if I use this feature, it's going to number them for me.
So I'm going to click plus in here.
And it says the S.M. operator initiates the acquire images.
And I'm going to hit plus again.
And it says the system prepares the imaging subsystem.
I kind of just keep hitting plus here.
And you notice it's numbering these steps automatically.
And now it says.
Imaging parameters.
And then it has the system validates the parameters.
So I'm going to pause here.
And now if I go back and look at my description.
Add this this behavior, which says it's an alternate flow, but it's really an error message.
So it's really an exception flow.
OK, and so what I'm going to do is with step four selected.
I'm going to.
Select that and then go to exception flow here.
And now I can add the type or a step.
So the type is invalid parameters.
Now I can specify the step here, and the step is.
Operator.
Fixes the parameters.
And then my next step is going to be.
Rejoin at step five.
All right, so now I've done this and now I'm going to show you what would be really cool about this particular feature if it worked right.
But this is where it's buddy.
OK, so if I click open and update here.
What it's done is it's actually created.
This activity diagram.
OK, so.
What's cool about it is that I only have to type it once and it actually creates a diagram.
Unfortunately.
It is.
Kind of.
Almost correct, but not really correct.
OK, so it'll say rejoin at step five.
Which would be here.
But if I try to actually correct this diagram to have this link up here.
It's liable to mess up my use case text.
OK.
And if you do any kind of serious editing on this diagram.
It's liable to crash cameo and.
Destroy your use case text.
So because of that reason.
I kind of recommend that you don't use this, even though it's kind of.
Very tantalizingly close to working correctly.
This capability is something that.
I don't know if you know about sparks enterprise architect, but it's sort of a competitive.
Tool to cameo.
And when I wrote my book design driven testing.
Which I think I have the book cover here in my slides.
I actually went down to Australia and met with the sparks people.
And.
I guess I don't have it there.
But they actually built this capability to generate.
An activity diagram from the use case text in sparks.
They call it a structured scenario.
And the sparks implementation of this works correctly.
So I kind of tried to copy that feature.
And then I suppose just lost patience.
With it and never really finished it correctly.
So.
It's a really cool idea.
But I sort of recommend that.
Instead of and now, by the way, I just go straight to the activity diagram if I click on that.
So to get into this use case specification, I have to go back here.
It will let you.
Change the text here.
So if I click on for.
Exception you see it's there.
I click onto it's not if I click on for it is.
So this is a really good way to think about use cases.
And if cameo worked better, it would be a really great feature to use.
But.
The world being what it is, it's kind of like I can show it to you, but not really recommend that you use it.
I would recommend that you write the use case in this format.
And you just do it here in the documentation field.
And I wouldn't number any of your steps until the end.
And I kind of write it in a block of English.
Just that looks like.
That.
You know, from here, you can draw an activity by hand and activity diagram by hand pretty easily.
And.
It's the best guidance I can give you.
I can't in good conscience.
Tell you to use this feature because I think you'll wind up unhappy.
And I don't want you unhappy with me for telling you how to, you know, that you should use a buggy feature of cameo.
But it is really, in my estimation, the correct way to think about use cases.
So that is all I plan to cover for today.
We are nine minutes.
Before five.
I'm going to stop sharing my screen.
And then if there is anything else you would like to cover.
I'm happy to chat about it.
I really wish I could tell you that feature worked.
Because it would be really cool if the feature worked, but it almost works.
Sometimes almost working is better than not working at all.
I feel like it would be just one more parallel option.
It would kind of compete with sequence diagrams and activity diagrams.
And there's just so many, you know, so many diagrams and views that you can create.
Same thing, but it just becomes this massive program with all these different opportunities and options for representing the system that, you know,
makes it difficult and I guess very artistic.
Yeah, well, if it worked right, it would save you a ton of time drawing activity diagrams.
Because it does generate the activity diagrams from the use case narrative.
But because it doesn't work right, generating these case diagrams is not quite viable.
So you can basically draw your use case diagrams by or your activity diagrams by hand.
But you're better off, in my brain, you're better off writing the use case in that style and then using that to draw your activity diagrams from.
That's how I would do it.
But, you know, I have another comment question. You mentioned earlier that, you know, people spend a lot of they do the functional.
That's something that, you know, I know our company does a lot.
You know, you just get into this endless cycle of decomposing activities into lower, lower activities, the lower level activities.
And then at some point, you know, for us, we're trying to cut off drawing these lower level activities into, okay, now the next level of lower level activities are going to be software activities.
You have any thoughts on that? To me, it's just it is this ever extending arm of activities that just goes, you know, in levels deep.
Yeah, well, a lot of your activities are going to be software activities, and they don't necessarily have to be very deep down the tree.
But what's what takes a lot of time and cameo is once you start putting object flows on your activity diagrams, then it puts pins on all the activities.
And then you have to name all your pins with input data and output data, and they get propagated onto the child diagrams as activity parameters.
And you're spending all this time thinking about inputs and outputs.
And that's where it starts to chew up lots and lots of your time.
So it may be that even, you know, your higher level activities are software activities.
But there's faster ways to figure out your input and output parameters than doing it with object flows, pins and activity parameters.
The pain level goes up a lot when you start putting object flows on your activity diagrams.
So what would you suggest as an example to, you know, as a more efficient way, that's definitely something we have a problem with.
You know, once you start doing that, especially when you have a whole lot of modelers in there, and somebody goes through an object, updates one object flow on one diagram, and then that causes a problem on the next level up and the next level down.
And then you got to go through and modify it on that one. That causes, you know, just pushes that error all the way up and all the way down.
Yeah, and you spin your wheels literally for months on that stuff.
And I wish I was exaggerating when I say months, but I'm not. Okay. You can spin your wheels on that for a long time.
So the way I do it personally is I don't put object flows on my activity diagrams at all.
I just use control flows. And that's kind of back to the original intent of activity diagrams, which is kind of like to put a little flow chart in there, right?
And so it's kind of a radical proposal maybe to some people.
But you'd be amazed how many problems it solves if you don't put the object flows on the activity diagrams at all.
Then you don't have the input pins. You don't have the output pins. You don't have the activity parameters.
And when you turn your activity into an operation, you just put in the parameter list of that activity, what are the inputs and what are the outputs?
And I'm actually kind of right now, my co-author Brian and I are actively considering writing another book, which is going to be called Pain Free MBSC.
Okay. And that's one of the things we're going to propose in Pain Free MBSC is since this is where you burn all the schedule time, just don't do it.
That's a great idea. If you can somehow get a hold of money saved by using that approach, I would love to use that as ammunition to change the system.
Well, it's going to be different for every company, and they're probably not going to share that data with me.
But, you know, if you just kind of think about it intuitively, do you need to specify your inputs and outputs? Yes, of course you do.
Do you need to do that on activity diagrams with object flows, pins and activity parameters? No, there's other ways that you can specify the inputs and outputs to your functions.
That is the slowest and most painful way that I know to specify inputs and outputs. And it's because, you know, I'm a software guy, right?
And as a software guy, you would just never do that. You would never draw a diagram.
Because just to specify an input parameter, okay, I have to rename the input pin, and then I have to go and, you know, look at a child diagram, and then I have to give it, you know, a type.
And it just freaking takes forever, okay? So, you know, and then what you get, and it's just what Daniel is describing, you get all these item flow violations, and somebody renames one somewhere and everything breaks.
And everybody's just like running around. I'm going to use a politically incorrect term, if you'll forgive me for using it, but we used to call this a Chinese fire drill, okay?
And it's like everybody's running around fixing these errors. And it wastes an incredible amount of time.
So for me, I like doing activity diagrams, and I kind of just say no to the object flows, right? I just think that in theory it's a good idea to do all this with object flows and activity parameters in practice.
It takes forever. So I'm kind of radical, you know, about some things. But what I've been thinking recently, and this is kind of a new idea, like a couple days old, to write this thing called pain-free MBSC.
It sort of hatched on me when I was teaching, I was in New Mexico last week teaching an on-site class, because I'm doing some teaching for Caltech now, and they sent me out there.
And I was kind of going through this with people, and then somewhere as the class was wrapping up that day, one of my students said something about, oh, you have this nice pain-free way of doing it.
And I was actually on the airplane flying home, and it dawned on me that pain-free MBSC has kind of a nice sound to it.
And I thought, well, maybe it's time for the next book, and maybe the next book is pain-free MBSC.
Because there's a similar thing that you'll see with IBDs where there's a way to avoid wasting all your time with IBDs.
And it's, you know, my experience is I taught hundreds of people at Boeing and other companies teaching from DeSoe course materials, from Boeing course materials, from Enola course materials,
and everybody always got stuck in the same places. And it's usually with the object flows, and it's usually with item flows on IBDs.
And we'll talk about that one tomorrow because it's when people try to do their item flows and they haven't defined their interface blocks, they get in trouble and they wind up chasing their tail around item flows again.
But that's, you know, when I've taught classes like this where we have labs, I know where all the students get stuck.
And then when I worked at that company with Brian, they didn't really know what to do with me when they hired me.
So they put me on helping a couple projects clean up item flow violations. And it was just horrific.
You know, they would give me these diagrams all full of red ink and tell me, like, go fix all these violations.
And I tried to say, you know, you can avoid all of these item flow violations, but they didn't want to hear it.
So I wound up not working at that company very long, but happily I met Brian when I was working there.
But there's like two or three places, and it's just about where the practices people follow result in 80 percent of the wasted modeling time.
And so when I built this course, I left out those places where you get stuck.
I just didn't put them in the methodology and the process at all. And those are the two main ones.
One is the object flows on activity diagrams and the other is trying to do item flows before you defined all your interface blocks on IBDs.
And I'm telling you, 80 percent of the trouble with the System L models come in those two places.
Well, you know, I always write books when I when I have a battle to fight and I don't want to, you know, go butt heads with anybody.
I just write another book. This is my ninth one.
So, you know, so you can do it the pain free way or you can add your pain back in if you're really, you know, so so in love with the painful way of doing things that you can't give it up.
But it really doesn't buy you anything extra. You still get the inputs and outputs on your functions.
You just do it in a less painful way.
Yeah, so I hope that helps. We are four minutes after five.
So I think it's it's time for us to wrap up.
We'll pick up tomorrow again at same time at 10 o'clock and we'll start talking about logical architecture.
And we'll go from that domain model into a logical architecture.
That's the third place where people waste a lot of time is trying to do logical architecture on a black box.
It's like, I have this black box. Tell me what the architecture is.
I do that. That's hard. Right.
So we'll do that the easy way tomorrow.
Thank you very much.
OK. You guys feel like this is on track?
You getting useful information here?
Yeah, I really enjoyed the last 30 minutes.
That was a great conversation.
And you really have some some great ideas that would tremendously help us.
Well, you know, the old cartoon, right, is the guy goes to the doctor and he says, Doctor, every time I bang my forehead against the wall, it hurts.
The doctor says, well, stop banging your forehead against the wall.
That's pretty much the way I teach this stuff.
Right. It's like, don't do the things that cause you all the pain and you'll have less pain.
So that's my two cents.
Alaina, you good?
I'm good.
All right. We'll see you all in the morning.
Have a good night.
All right. Have a good night.
Oh, save your cameo models before you before you leave.
I'm going to leave my connection to that virtual machine open overnight.
But save your cameo models.
All right.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Finally, Patton is leading the kind of attack he craves.
A swift assault and a strike on the heart of the enemy.
The war wallet is always in danger.
Criminals can scan and hack your information without even knowing.
Where's Jeff?
He's bulky and soon disorganized, but not anymore.
Because SLIM is in introducing SLIM, an ultra-thin RFID blocking wallet
that keeps your cards and cash truly protected.
And now may be your last chance to get it for a low price.
SLIMBIT uses the latest RFID blocking technology
to prevent thieves from scatting your wallet and stealing your info.
Having your information stolen is a nightmare.
But with SLIMBIT, I know I'm protected.
With buddy clips, cash can easily fall out.
But with the auto-locking SLIMBIT, your cards and money stay securely in place.
Then just press the button to release the lock.
SLIMBIT is ergonomically designed to optimize space and keep your belongings organized.
It has a built-in cash flip and a flexible outer band
to securely fit your additional cards in your extra cash.
Even with everything you see here in the SLIMBIT, it's still ultra-thin.
Booking wallets are uncomfortable,
but the SLIMBIT is so compact it fits in any size pocket.
Plus, it keeps everything easy to access.
SLIMBIT puts everything from pictures to credit cards by driver's license.
Yeah, it's still so thin.
It's a pipeline of bent cards and damaged magnetic strips.
SLIMBIT keeps them protected.
It's crush-resistant.
It can really make a beating.
Similar wallets over over $100.
But color-click now and get SLIMBIT for just $29.99.
Order in the next five minutes and you'll get an instant $10 discount.
So it's only $19.99.
But wait.
To the pricing cost and supply chain shortages,
this may be your last chance to get SLIMBIT at this low price.
There's a strict limit of free SLIMBIT wallets,
while supplies last.
You still have time to get your very own SLIMBIT wallets,
but you must act fast.
Don't wait.
Order now.
Call 1-800-84135-05.
Call.
Visit slimbitwallet.com.
So call 1-800-84135-05.
Order now.
Attention.
If you or a loved one were diagnosed with mesothelioma or lung cancer
after being exposed to asbestos,
even if you smoked, call the victim's justice group now.
You may be entitled to money damages.
A $3 million full-order trust fund has been set aside for mesothelioma
and asbestos patients and their families.
Since the 1970s, many companies did little or nothing
to protect workers from dangerous asbestos exposure.
Asbestos exposure can be devastating
and may have occurred while performing work
in these industries and trades listed on your screen.
If you worked in any of these industries
and were diagnosed with mesothelioma or lung cancer,
call the victim's justice group now.
The average mesothelioma claim is more than $1 million.
And often, payment received in less than a year.
If you or somebody worked in any of these industries
and trades listed on your screen
and was later diagnosed with mesothelioma or lung cancer,
even if you smoked, call the number on your screen right now
to get the help and financial compensation you deserve.
The M1A1A-Rosane battle tank
is one of the toughest and most lethal killing machines
on the battlefield today.
Yes, sir.
Get the main objective.
Go out and rip open the enemy armor
like you can't open it with an axe.
Fire!
From the nation's pride to the modern marine,
experience the soldier's history
of modern military history.
Just days after fighting his way on the beaches of Sicily,
General George Patton's army is on the move,
leading an armored charge on the capital city of Palermo.
Albert Kesselman has no intention of sacrificing
the cream of his army on Sicily.
He orders the German forces back to the northeast
to do so on a high ground around Almedna.
Now, at the stand between Patton and Palermo,
our disheartened and poorly-trained soldiers
of the Patriots block their approach to the enemy
as they advance into the enemy territory.
The enemy left them scared to death.
But to the east, as all our enemy troops push farther away,
they once again come face to face
with a hardened kill of a soldier on the capital regions.
As the big man rides his way through a small town,
Andrew Jacobson and his rifle platoon
make their way up one of the narrow streets,
searching for enemy infantry.
Suddenly, as they approach the town square,
they run right into a Mark VI Tiger tank.
When he comes out, he takes a look around
to see what's going on,
or where the whole town plate comes forward
if they're there.
Jacobson's platoon leader calls for a bazooka
to take the enemy Tiger out.
Thinking he might get him out,
Jacobson volunteers.
They throw that thing under his silver star.
Slowly, I get him, slowly,
I get off to one of those monitors.
Jacobson takes a position,
ready to hammer the Tiger
and expose him round from the bazooka.
Suddenly, as the turret slowly turns towards him,
Jacobson finds himself staring down
the Tiger's muscle.
And I move to the side,
so I take off her cover.
In my wrong eye, the Lieutenant says,
you want me to hit your silver star?
No.
But yeah, that was an incident, wasn't it?
Yeah.
Tiger tank is here.
It is later that your comedian tanks
and artillery come within range
and cut loose on the Tiger.
Another town falls to the G office
of the big red line.
60 miles west,
a town in the 7th Army
is indicated as a polar bear.
You don't want this.
I mean, it's only a matter of time
before you're going to give up.
I mean, who's going to stop George S. Patton?
Friday, on July 23, 1943,
four days after getting bombed
by his cavalry charge,
Patton and a triumphant 7th Army
over to the polar bear.
This isn't the camp that has been bombed
by the Americans.
This is simply a tree
that's army by concrete trees.
See, yes, that was great.
But I tagged it out.
And then a whole lot of American fans
are saying that it isn't even great.
It's a great city.
The western system will soon fall.
It has garnered great headlines.
As Patton vests in the glory
of his triumph,
word reaches the allies from Italy
that dictator Danito Mussolini
has been removed from power
by King Emanuel III.
Mussolini is under arrest
and has been placed in an isolated prison.
The Italian-German alliance
is threatened.
I'm going to show you
how much they put out of power.
They heard about it.
And the war is going to end.
Let's go home.
For Patton's 7th army,
the war is anything but over.
Now, with his right on Monteverde,
he's still bogged down on the far side of the island.
United's gaze turns to Messina,
the final step to victory.
If he can beat Montgomery
to Messina, Patton
will claim ultimate glory
of the battlefields of Sicily
for himself and the U.S. army.
And once you have success,
it's very hard to stop.
And once you've got Patton having success,
it's impossible to stop.
Despite the horrific friendly fire tragedy
in the skies over Sicily,
Patton had to be redeemed.
In less than two weeks,
he has led the largest American invasion
of World War II yet.
Faced off against the Tigers
and the Hermanns killing each other,
Patton has captured the capital
of deliverance and the body
of his bloody fascism.
But for Sicily,
it's just getting started,
and he's only a few feet close to him.
He's got to rise from his small room
and he has to
fight a retreat
that falls back
once he's defensive enough
so Patton is ready
to face whatever castle
and something he had to offer.
In a letter
to his wife Beatrice,
Patton writes,
We're as far from home.
We're going to bed in a big way.
I have not the least notion
what will happen next time,
but I don't care where,
men, or what we fight.
So long as I keep fighting,
it is the greatest of all games.
In a matter of days,
Patton and his army
face their greatest challenge yet.
As the battle for Sicily continues,
his troops must go up against
the Hague rocket
50 miles on fortified enemy highways.
Here,
the Germans can block
every movement that moves.
It will be a race to the
finished line of the Siena.
The German army is digging in,
ready for a fight to the death.
From the battle front
to the home front,
throughout the ages,
in stunning CGI,
in dramatic detail,
they have their own individual words.
I saw, I saw
their bodies.
I knew their history.
Just at the top of the base,
just behind that base,
a massive rock moved in.
The rocks moved away.
We are going to lose.
We are going to lose.
We are going to lose.
We have this amazing
fight going on.
been there.
Thank you,
You
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Despite intelligence reports about massive buildup of allied troops in England, when D-Day came, Hitler's defenses along the French coast were unable to contain the avenging tide.
In the initial assault, more than 6,000 allied ships, 13,000 aircraft and over 160,000 troops swarmed across the English Channel.
Within a month, a quarter of a million additional men and a useful number of vehicles were clapped on the continent of Ohio.
With their efforts now split between the allies in the West and the Russians in the East, the Germans simply could not resist the onrushing wave of destruction.
Although it must have seemed like an eternity for the Brits and the Afghans to invite, success came relatively fast.
By the end of July, the Allies had broken out of Normandy.
Now, British and Canadian forces drove through Belgium on their way to liberate the Dutch portal Antwerp.
Simultaneously, the Americans ran out east and northeast across central France towards Belgium and Luxembourg.
On August the 25th, 1944, Paris was liberated after four years of German occupation.
By September the 3rd, less than three months after D-Day, Brussels was liberated by the British, and a week later, Americans reached Tarkin and the German border.
France had been free, and American troops were always to cross the sea-free line, a massive number of defensive works protecting Germany's western border.
In the late 19th and early 20th century, France was the first country in the world to have a border with the United States.
In the late 19th and early 20th century, France was the first country in the world to have a border with the United States.
In the late 19th and early 20th century, France was the first country in the world to have a border with the United States.
In the late 19th and early 20th century, France was the first country in the world to have a border with the United States.
In the late 19th and early 20th century, France was the first country in the world to have a border with the United States.
In the late 19th and early 20th century, France was the first country in the world to have a border with the United States.
In the late 19th and early 20th century, France was the first country in the world to have a border with the United States.
In the late 19th and early 20th century, France was the first country in the world to have a border with the United States.
In the late 19th and early 20th century, France was the first country in the world to have a border with the United States.
By round-the-clock ally bombs, Germany's district could no longer replace the last equipment.
Hitler's Germany was deemed land-tracking.
The German army was used as a base for the German army.
The German army was used as a base for the German army.
The German army was used as a base for the German army.
Despite the monster and shrinking military, Germany called on every man between the ages of 16 to 60, and threw him into the fight to save the party.
But still the Allies came.
By the end of September, the British had opened the port of Antwerp to Allied shipping.
And less than a month later, French troops moved through the Alsace region and stood upon the backs of Germany's private.
If the German military was not unwrapping fast enough in the field, strife in the high command only made matters worse.
Three weeks after Ida, General von Rundstedt, Hitler's commander of all troops in Western Europe, resigned from the service.
Two weeks later, the massively popular General Erwin Rommel also resigned, leading German troops in occupied France with virtually no experience in the US.
If Adolf Hitler could not reorganise his army within a few weeks, his thousand year ride would collapse before France.
But there was no ray of hope against the disaster.
If the Allied invasion sank straight from Germany, the speed of their advance would have stretched allies and allies and now part of the German army.
Adding to our problems, by September the days grew shorter and the sunny weather turned to constant rain and fog, reducing their ability to keep pressure on the retreating Germans.
In November, General George Patton Sternhardt had reduced its number of missions from an August high of 12,000 a month to fewer than 3,500.
Six months of relentless fighting in Marching, followed by weeks of rain, slowed the Allied advance to a pull.
Hard to believe you can get all this in just...
Hello, Merlin! Hello, Merlin, is something wrong?
My wife and I are on the plane, dear, from the U.S.A., facing Darwin.
What is your name?
I heard it cost them more to press the doctor.
Doctor what?
She was a dinner with Mr. Timmons and her brother.
Very well, Merlin, that's all.
Yes, sir.
Dr. Moorheadman, to what do you approve of the death of Sir Charles?
Hardly, sir.
Like my dad, there were sometimes the troubles of a high nose tape.
Right.
Something was praying on his mind.
And if he could find you, what was praying on his mind?
Well...
Well, what about this footprint, sir?
Is there a chance of him tilting back towards the house?
I tell them myself, and there's a man of silence who lives in the single room.
Well, ladies and gentlemen, my name is Merlin, running from cost.
If you'll please, gentlemen, one at a time, I urge you to tell the truth.
I love you.
Tell all you know. Silence, Mr. Franklin.
You've already testified you were not there.
Nobody would ever have this manner.
Nevertheless, I insist, he was murdered.
I can not tell you that, but you shall think what you will.
There were no marks of the money or any kind, Dr. Moorheadman.
Then as his position, what would you say was the cause of Sir Charles' death?
It was a particularly hard video, sir.
Such then as your foot is the verdict of this horrible thought,
crime or killing, Sir Charles was murdered.
There's more than one person in this room.
No last feet are true.
I'm blessed by Mother's passion, Mother.
I have an idea what it's going to be every day.
I've never been in this world.
What?
My injector is the movie, Merlin.
Merlin?
Very interesting to see you.
My exceptions are the insurance.
Mr. Holmes, what are you out of touch with?
We're called to see your registration.
Do you have three?
Oh, no, sir.
We just went to the mistake.
And Dr. Moorheadman?
He didn't leave his name, sir.
Let me just get on the stick, Mrs. Hudson.
Was he? I didn't notice.
Do you know where Dr. Moorheadman was?
Where did he work?
He didn't stay, sir.
What are you making a fuss about?
Why should I make a fuss?
It's none of your business.
Let me hear you reconstruct it from your small stick.
It's not a elementary observation.
Well, I should say that Dr. Moorheadman is a business man.
Well, let's see.
Oh, this isn't going to work.
Mr. John Holmes is one of his friends.
His friends are Steve, C.A.
Steve, I should say.
He's a friend of mine.
He's so lovely.
His name is Jamie.
He's a friend of mine.
A friend to a doctor, I'd say.
And all I think of him must be a man.
And my medical student sees the array of all the hospital
with the name of Cherry Cross Hospital
rather hotly as it presents itself.
It may be blood.
Furthermore, I think that Dr. Moorheadman
had a small practice in the country
and was the owner of a dog.
As you can tell there.
Not simple.
From the teeth marks,
looking to see his dog.
Not the most undigest dog, I'd say.
And I'd like to say that Dr. Moorheadman
will call on us again in a few moments.
Rush, Holmes.
Rush.
Hello, gentlemen.
How do you do, sir?
Well, as he does,
his ticket is reasonable to presume
that he'll come back again.
Dr. Moorheadman?
Mr. Holmes?
Yes.
Tell me, Dr. Moorheadman.
I'd like to know about your ticket.
Oh, sorry, please.
Thank you so much.
Your presentation?
I see.
Yes, sir.
Tell me about your ticket.
This is my friend, Dr. Watson.
Of course.
How do you do, sir?
Mr. Holmes.
You're not one of many more people
than I am.
Would you sit down?
Thank you.
A friend of mine is in great need.
May I know who I am, sir?
Jerry Baskerville.
Yes, Mr. Baskerville.
Paul.
I've been bothered here
to get this life for me.
It's found out.
I won't make you leave there.
I have information to give you
that the EECO Center is passing
everything Baskerville was getting
in the estate since the end of the fighting.
It was sudden death.
But the man who called it a child
actually caused his heart failure.
Anarchy.
And that was the verdict of the coroner
in which I, as a child physician,
was heard.
But it was point-and-point
which I came back
and the police,
not everybody,
there,
about 20 yards
from where Sir Charles Hellgate
were.
From the Prince.
Commander Lawrence.
His house.
They were from the Prince
of the United States.
How?
Oh, I didn't do it for you.
What I saw was the EECO.
During the 1980 raid,
there was a boy in the box
who took me over to the EECO,
but I saw him.
That's clear.
And then,
a few days ago,
I wanted to send him
to the estate.
It's all done.
Legend of the Hound
of the Baskervilles.
Have you taken these two
to Mr. Holmes?
It's quite short.
I won't bother you
with my promise.
Yes, please, go on.
In the time,
I turned sixty-fifty.
Baskerville's matter
was the operation
of that day.
The same time as this,
this year,
sold out on a day
He's been shot
He's been shot
and killed
in a desert island
country side of the world.
country side of the world.
Come on, I said.
I'm not certain
or who it was.
Can I do an experiment with these books?
I know you're saying you're telling me to do it.
What do you think? I don't know.
What do you think? I don't know.
You think you're asking me to do it?
I was trying to get you to do it.
Do you think you need to pretend that you're asking me to do it?
Or do you think you might just ask me to do it?
Or can you get yourself to do it?
That's not what I was looking to do last night.
That's not what I was looking to do.
I don't know.
That's what I don't know, man.
You haven't done it.
I used to have a dog.
A small one.
Good.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
That don't make any sense.
I don't know what that was really.
I don't know.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Hi.
Okay.
Got any feedback for me on yesterday?
I think the only thing was just like I think what we talked about was just like reading the slides and just I think to me it's like bridging that connection between directly integrating the AI exports and putting them into the model.
Even like, right? I get the table, but it's just like maybe, you know, do we, you know, and that's what I don't know if we're going to do that today, right? Using our own exports from ChatGPT and then importing it themselves in there.
So there's no real automated solution yet that works completely well. There are several plugins that I know about that are kind of work in progress plugins that they're kind of cameo plugins with AI inside them.
Yeah, sure.
I guess I'm not even talking about just like the automation of it, even if it's just manual, manually putting them in.
But it's just like it's just like bridging that connection of like, you know, you're creating the framework or do you create the framework and then paste it in there or, you know, and it's not pasting it in or even if it's hand jamming it in.
Yeah, so, so you're welcome to, you know, try the prompts in the book with ChatGPT and create a lab exercise that's a little bit different than the one I'm presenting.
But for teaching purposes, you know, in particular for kind of teaching hands on cameo, it's easier to good morning, Mark. It's easier to just kind of follow the example that's in the book.
Yeah, that makes sense. You don't know what the range of students are going in. For today, should we be logged into ChatGPT on our virtual desktops?
So you can if you want to experiment with it. I mean, my plan going in for teaching is to
just have you follow the electron microscope design that I did.
And so I think probably the point where where you're going to want to really use ChatGPT
is to experiment with the code generation, which is going to be tomorrow.
The cameo stuff, I think it's easier to just kind of follow the example that I did.
But, and you can look at the ChatGPT output in the book and then see how I translated it.
But like I said, if you want to experiment with ChatGPT and, you know, because it doesn't give the same answer every time.
Right. And so, you know, if you give it the same prompt, you may get a slightly different response.
And that's OK if you want to do that.
But I think for teaching the cameo aspect of this and the system part of it, it's probably going to be easier to just follow the diagrams that are in the slides.
And I think you'll see, like I was looking at the next slide deck that's coming up.
And I mean, I can kind of, well, I'll wait till the class gets here.
But there's, you know, there's BDDs and there's IBDs and there's interface blocks and there's all this kind of stuff that's in this logical architecture section.
And I think it's going to be easier if you just follow it, you know, for, you know, I guess there's some there's some tradeoffs that I can make in how I teach it.
But my plan going in, especially for if I if I understood it right, you're not as much of a hands on cameo expert.
And that's probably part of what you want to get out of the class.
So if you want to get that out of the class, then it's going to be easier to just kind of follow the design that is in the PowerPoint.
All right.
Mark, you got any feedback for me from yesterday?
No.
Yeah, I like the bass.
I'm learning a few things.
The repercussions are huge.
I'm realizing it's more than I thought, to be honest.
I thought, okay, that'll be interesting.
Now I'm realizing this could be really disruptive.
So, yeah, it I think it will be I think the way people do systems engineering two years from now is going to be very different from how it's done.
Unless of the ugly grunt work of connect up this interface in this flow, which aren't correct because somebody else did it differently on the other side.
Yeah, this is definitely surprises.
And I mean, I'm going to amplify or follow up on what Daniel said yesterday.
I think the whole session was really good.
And then that last little thing about, you know, the flows.
I mean, that could have that made the whole day worth it on top of everything else.
Well, I'm going to wait till Daniel gets here.
But I didn't do a lot of work last night.
But I did ask chat GPT to come up with a cartoon of someone going to the doctor saying, doctor, my head hurts every time I bang it against the wall.
And I kind of like what it came up with.
And I then had it mock up a couple of potential book covers.
And we're going to start the day by me showing those to you.
And you get to vote on whether whether you like this theme for a book cover.
But it's really, you know, there's it's really kind of there's this small set of common MBSC practices that really take most of the time.
And I think if if somebody like me points out what that set of practices are, then there's kind of maybe some some chance to get them changed a little bit.
Good morning, Daniel. We're just chatting for a minute.
If you have any feedback on yesterday, I'm happy to hear it.
Good morning, Doug. I do have a question.
But sometimes I'm not going to be able to take advantage of the caramel.
So it takes a second. That's OK. Did you bring stuff for did you bring stuff for everyone?
I've worked with my wife. Right.
Are any of you Blazing Saddles fans?
Because it's like there's the line when they're they're rounding up all the thugs and one of them chewing gum.
It's like, well, I hope you brought some for everybody.
OK, so so I have a question I was going to ask you earlier yesterday.
I completely forgot. We just kept moving on.
But, you know, I'm trying to get your I'd like to get your perspective on a balance between, you know, creating an accurate model.
Because, I mean, you know, we want to be the source of truth for a lot of things.
And so we want to make it as detailed as possible.
You know, put as much information in there because, you know, we've got, you know, mechanical engineers, systems engineers and electrical engineers.
And we've got the customer who are all going to be using this model.
We all want everybody to find value in it.
But then there's there's a big line of, you know, you know, what is what is, you know, OK, what is representative of the system and good information, the technical information from an engineering perspective versus that's not really easily.
You can't use some of these diagrams that we have for technical information to present to the customer.
So, you know, what is your thought on where do we draw that line between, hey, it's a good source of technical information for engineers versus we want to build something that is easily understood by the customer and all users of the model.
Yeah, so what triggered my ears when you were just talking was the presumption of we want to put as much in there as possible.
OK, sometimes less is more.
OK, so I'm 100 percent with you on it wants to be accurate.
It wants to be the single source of truth.
I'm 100 percent with you on that.
That doesn't necessarily mean putting more stuff into the model.
Right.
So I use a philosophy of value add.
OK, before I put anything in a model, I'm asking the question, does this add value?
And, you know, more than just does it add value?
Yes or no.
It's kind of a a trade off between does this add enough value to justify the effort in putting it in there.
And that effort can be both on the part of whoever creates the model and who all the people that have to consume the model.
Because the more stuff you put in, the harder it is for everybody to digest.
So and it's a subjective thing.
Right. It's it's not there's not one objective answer all the time.
But you're kind of leading me into where I want to start today, which is, you know, my experience has been that it's really a small subset of.
The system processes like a magic grid or an awesome that take an inordinate amount of time.
So you've heard of the 80 20 rule, right?
You get 80 percent of the value from 20 percent of the stuff.
I kind of think with system now you get about 90 percent of the value from about 10 percent of the stuff.
And how do you identify what what is that 10 percent?
And, you know, that's kind of the trick.
Right. That's where experience comes in.
And so what I'm trying to do is share my my experience with you and then keep in mind that your experience may be different than mine.
And so, you know, but I can give you my perspective and my two cents on it.
Does that sort of address your question?
Yeah, I mean, it does.
I mean, it's it's it's very nuanced question and not 100 percent agree with you that it's.
It's a very complicated question because if you ask one person, you're you know,
each person you ask is going to say, you know, it's going to have a different perspective on what a value add is.
And I have not heard a.
A clean answer to this, because, you know, again, it's one of those things where, oh, we want to prioritize requirements.
You know, OK, well, you know, how many, you know, OK, well, we prioritize requirements.
But then, you know, we map out a lot of the requirements, satisfaction to, you know,
activities or to some parameter that's associated in the model.
And then, you know, we just got to keep dialing that down to lower level, lower, lower, lower the requirements down to the lowest levels of where they're satisfied.
And then sometimes, you know, in order to represent this level of detail, you know, you need to have, you know,
other diagrams or associated systems, you know, modeled out to be able to fully represent that.
It's just kind of one of those things where.
Yeah, so there there there there is a there's a line between.
Enough and too much. Right.
And where that line is, is going to be a subjective judgment on the part of.
Who's doing the work and kind of on the part of who's setting the standards for the team.
And what you sort of have to recognize is.
There's such a thing as the point of diminishing returns and where is it right.
And when you hit that point of diminishing returns.
Then you need to stop and and that judgment is.
Is difficult, so I didn't do much work last night, but I did do one thing and I'm going to share it with you now.
And.
I'm going to get your votes.
On.
What you think of this.
So.
Late last night, I went on to chat GPT and I said.
Make me a cartoon of a guy going into a doctor's office, telling the doctor.
Every time I bang my head against the wall, it hurts and give him a bloody forehead.
And so that's what chat GPT came up with.
I kind of liked it.
And then I gave it another prompt, which I said.
Can you integrate that into a potential book cover for this new book?
I'm thinking about called pain free and BSE.
And.
That was his first attempt.
Which.
I kind of like.
And then I asked it to correct the subtitle and it's one of these things where it'll never give you the same answer twice.
So I kind of really wanted it to repeat all of this, but just change the subtitle.
But it doesn't do that.
And then it gave me this one.
Which some aspects of it I like a little better.
Of course, it can't.
Literally spell things out very well.
Sometimes it does like it actually.
Yeah, it didn't quite get this either.
Right.
It's like, but it did get it down here.
Every time I bang my head against the wall, it hurts.
And.
I happen to like.
I like the doctor's eyes here.
He looks like Marty Feldman, the actor.
You know, he put the systems engineer in a doctor's coat, which is kind of not quite right.
But I don't know.
You think people would buy a book like this?
I'm not into the blood, although maybe a bandage around his head.
Okay.
Yeah, yeah.
I mean, I don't care about the blood.
I like the content, to be honest.
But yeah, I'd say maybe the skull, the top half of the skull was there.
It still had all the little sprues and stuff.
It would probably be less bad.
You know, the rescue.
Well, you know, the idea of a bloody forkhead, right, comes from there.
Oh, okay.
Yeah.
So this is the whole theme of the book, right?
Is that when we do this modeling, we're basically banging our head against the wall over things like my pet peeve is item flow violations.
And everybody gets a bloody forehead from dealing with these.
They spend hours and days and weeks chasing item flow violations in their activity diagrams and on their IBDs.
And the additional value that it adds to me is not worth the time that it takes to do them.
So what this book will be is basically, if we write it, but it's going to be me and Brian sharing our experience with this.
And, you know, my experience is largely from watching people get stuck in training classes and a little bit on projects.
But Brian's experience is pretty much all project-based because he was kind of Mr.
Fix-It at this company where we met.
And all the stuck projects would always come to him to get unstuck.
So I think it's kind of a nice balance between the two of us.
And, you know, when I put this course together and wrote this book,
I sort of built it around what I consider to be the pain-free process.
But I didn't actually, you know, it's kind of in the in the way everything is presented in the book and in the and in the marketing.
AI is really the big attention grabber.
Right. But I kind of sneakily snuck a different MBSC process into the book.
And what this book potentially would be is let's forget about AI for a minute and let's forget about software for a minute
and just focus on how can we be more efficient and do things in a little bit simplified way with with AI.
So anyway, that's what I was doing late last night was was working on that concept because I think I think that book needs to be written.
I feel like, you know, it's just that the whole industry is sort of plagued by this.
And it's kind of actually this module that we're going to start with this morning is where a lot of that happens.
So what you're going to see in this particular slide deck is kind of it's one of the key ones in the class because it's how do you do architecture without getting stuck.
And that's the that's kind of the six million dollar question.
Right. Is that a lot of people have the impression that the only way you can do an architecture is by decomposing these activity diagrams and putting on the object flows and the pins and all that.
And I'm going to show you a different way to do architecture, which I think works.
But we'll see what you guys think about it.
And you're going to get labs on working through all this stuff.
And just to talk to Elena for a second, because we were having a little bit of a conversation before you guys showed up about whether you should be using chat GPT to do this.
And I was suggesting that at least for the system part of this, it's maybe better if you just use the diagrams that I put in the slides.
So I'm just going to quickly flip through some of these.
And so we're going to start with identifying subsystems.
And then we're going to go define interfaces.
And we'll put flow properties on the interface blocks.
We're going to create signals.
We're going to do IBDs with ports and interface blocks.
And we're going to start doing state machines.
And then we're going to go down and start decomposing subsystems into their parts.
We're going to put a microcontroller in our subsystem and we're going to talk about algorithms and do all this.
If you look at this activity diagram, you'll notice that there's no object flows on it.
So we've got swim lanes representing the various blocks, but it's all control flows and no object flows.
And so we're not taking things down to the parameter level on these IBDs.
But it then does become code generatable.
And so we're going to spend a fair amount of today on working through this exercise.
And you can do it by prompting chat GPT yourself.
But I think the more efficient way to do this and get through all the labs is going to be to just kind of
look at what I did with what chat GPT told me and then kind of follow it and then raise any questions you have about.
And you all have the book now so you can look and see what chat GPT's output to me was.
So that's what's in front of us that we're going to jump into now.
So last questions before we start.
Oh, a quick comment.
Maybe for the picture, which are nice pictures.
Another option might be a wall with like Bank C versions of item flows and whatnot on it.
Yeah.
You know, some complex IBDs on the wall.
Oh, that is the wall.
Bloody, bloody forehead prints on the item flows.
So, but, you know, you're going to know me a little bit, right?
Like this is how I think.
And I'm like, if the industry does something dumb, you know, I'm going to write a book and say, you know, this stuff is dumb.
And I'm not bashful about it.
I've had a long and relatively speaking, fruitful career.
And I kind of don't really care who I pissed off at this point.
So, you know, that's kind of how I approach things.
But the real question is, you know, would would you consider going to a training class on pain free MBSC and recommending it to your, you know, to your friends?
Right.
If you become convinced that you actually can do this stuff in a less painful way, you know, because that's really what, you know, I think people who write books, maybe I'm generalizing, but at least for myself, I write books when I see things in the industry that are broken.
And for some reason I have I have whatever skill set it is that allows me to write books.
And so I try and do it when when the industry needs changing.
But the book that this sort of reminds me of, it was actually my third book, I think, is when extreme programming came out, which is the forerunner for agile software development.
I wrote a book with Matt Stevens that pretty much just trashed the extreme programmers and had a lot of fun writing.
It was completely a satire book.
I would buy it.
Okay, I think, you know, my comments on that is that, you know, when you talk about pain free, you know, basic model based system engineering.
I think that there's a huge gap right now between, you know, the people who know SysML and know MBSC and know Cambio and all of the other systems engineers who've been doing systems engineering forever.
There's a huge gap between those two.
I think that was some kind of intermediary course, which isn't going to focus necessarily just on SysML, but at the same time, not get too much into the weeds of all the details of everything.
But, you know, it's just kind of a medium introductory course that's going to help people faster adjust and to be able to, you know, to succeed in a model based system engineering environment.
That would do really well.
Okay, cool.
Thank you for the feedback.
We'll see if I get a book contract to do this one.
It's gotten to be really pretty easy to self-publish your books like on LeanPub, which is where that PDF that I gave you guys, you know, was published.
You can actually just go do all of that yourself now.
And so I used to have to, you know, bow down to what the editors wanted, but kind of don't now.
And my friend Brian has a huge following on LinkedIn and on YouTube.
So, you know, we could conceivably do this book ourselves if we don't get a publisher to buy into it.
But we're starting to scout around.
This is a very new idea, actually, this pain-free MBSC book.
But anyway, so without further ado, let's go talk about how to do logical architecture in the most pain-free way that I know.
And that is to kind of adopt this philosophy of domain-driven design that is very, very popular in the software world and kind of apply it to systems engineering.
And what that means is instead of doing a context diagram and then functional decomposition where we break functions into sub-functions and the sub-sub-functions, we actually start with a model of the problem domain.
And we take more of an object-oriented approach to kind of distribute the behavior among the blocks.
So, I call this DDLA or Domain-Driven Logical Architecture.
And basically, this is one of the pain points that I want to talk about in this pain-free MBSC book is that the current state of the practice is you think of your system as a black box and then you start breaking it down.
Into functions and sub-functions.
And in my opinion, it's very difficult to architect a black box because by definition, if it's a black box, you don't know what's in it.
And if you start with a domain model like we did yesterday, then you're kind of starting with maybe a gray box or a white box where we actually do have some idea of what the basic parts of the system are.
And I think in most cases, for most systems, you really do, you have some high-level idea of what the pieces of the system are or what the parts of the system are.
And if you model the problem space, and you don't have to take a long time to do it, you can model the problem space in an hour or two, even without AI.
And with AI, you can model the problem space in literally just a few minutes.
But if you understand the problem domain and you come up with a common vocabulary for discussing the problem domain, then you can build your architecture around that set of abstractions.
And it turns out that that's the set of abstractions that is more stable over time than a set of functions or a set of requirements.
And when you're talking about, Daniel, how do you communicate this with other people that maybe aren't systems engineers, this is a big step because you can define your project glossary quickly.
And if you have non-systems engineers and you misstate the problem domain, they ought to be able to understand that and correct it.
And if you're misunderstanding the problem domain, the sooner you catch it, the better off you're going to be.
So what does that look like and how does it work?
So the one that's in yellow is one of the big ones because your requirements are going to change more often than your problem domain does.
And I'm now being from the Department of Redundancy Department because I've said this five times already.
But there's a reason I keep bringing it up and it's because I think it's really important.
So when your requirements change, you would like your models not to just break.
And if what you're doing is functionally decomposing everything from a black box, you're going to get these trees of functions.
And when your requirements change, they're all going to break.
And if you've been on a few projects that have been done that way, you likely have experience.
Let me ask, have any of you ever experienced that?
Where you get this set of functions and then three months later the requirements change and you've got to go back and rework it all over again?
Has that ever bit any of you?
Definitely yes.
Yes.
Alana?
No.
I understand what you're saying, but that's not the type of modeling I've been around.
Okay.
So two out of three ain't bad, I guess.
So, you know, so improved communication, we're going to use this domain model as common vocabulary.
And then the next bullet I think is really important because if you're not doing functional decomposition, how are you decomposing your system?
Okay.
And what I like to do is I like to do subsystem decomposition.
And that's what we're going to talk about in, you know, today and in particular in this slide deck that we're looking at now is, you know, you have to have some way to decompose your system, right?
But what's the better way to do it?
Is it functional or is it subsystem?
And I'm proposing subsystem decomposition.
And today you get to work through a lab on that and see how you like it.
So we start out by modeling the problem domain, and we did that yesterday, and you leave all the implementation details out of it.
And then there's a point in time, and it's when you switch from conceptual modeling to logical modeling.
And I think let's see if I still have my grid up here.
I do.
So yesterday we kind of went through this top row of conceptual modeling.
And then you would have something like an SRR, you know, system requirements review.
And then after that you pass that review, then you start switching over to logical architecture.
And what's here in the structure column under logical architecture is this define and decompose subsystems.
And then define the interfaces between those subsystems.
So this is where we are in the chart, okay, in the overall process view, is we're about to do this.
So I use this term recursive subsystem decomposition.
And I want to talk about that and what I mean by it.
So you start out by just kind of identifying all the subsystems in your system.
And then you take those subsystems one at a time, and you break that subsystem into its parts.
Well, sometimes you're going to have a part that is itself a subsystem.
But eventually when you get down to the bottom, your parts are going to be components.
And so what I mean by recursive subsystem decomposition is when I have a part that is itself a subsystem, I decompose it again.
And I do that until all the parts of whatever subsystem I'm doing are at the component level.
And then I'm done decomposing.
And one of the issues that happens with functional decomposition, and I think we talked about this yesterday, is there's no clear guidance on when to stop decomposing functions.
But if you decompose subsystems instead of functions, there is a clear guidance on when to stop.
Because when my part is a component, I stop.
And so it kind of solves.
You may remember we talked about there's two big problems with functional decomposition.
One is not knowing when to stop, and the other is trees of functions are not resilient to changing requirements.
Well, this solves the first one of those problems. You kind of know when to stop. Does that make sense?
I think both of you Raytheon guys had said that, yeah, not knowing when to stop is an issue.
Am I remembering that right?
Yes, okay.
So beyond the part, you start getting into lower level functionality.
Certainly when we have our structure below that is the software architecture. Yeah, and that may be true.
But in a lot of cases, it's going to be software way before you get down to the bottom.
So that's not necessarily a guideline that's always going to work.
Because if what you're decomposing is a subsystem that's already mostly software, then because you can still decompose software.
Yeah, I'd like to follow up on that.
Just a note, when you have project usages, it makes things more interesting.
So I'll leave that open, but it's something that we face.
Yeah, you have projects that use other projects.
Yeah, that's not one I'm really going to go into.
But if you have comments that relate to it, please bring them up.
So when I asked chat GPT to tell me the top level subsystems for an electron microscope, this was the result that I got.
And, you know, if you want to try this with chat GPT yourself, you'll probably get something similar.
But it may not be exactly this list.
But in general, chat GPT is trained on the whole Internet and it knows it has a bunch of domain knowledge about electron microscopes.
And it should come up with a list that's fairly similar to this.
So what do we do with this list is we turn it into a BDD.
And this is going to be the first part of your hands on lab exercises today.
And we'll go make this model in cameo and you'll get some some hands on practice.
You'll notice that some of these are actually most of them are using the subsystems stereotype on on the blocks.
And so it may be early in the morning for lab, but I'm going to throw you back in the lab now and we'll do this subsystem diagram together.
I'm going to put it on my other screen here.
Is there any particular reason that, you know, basically all of those subsystems are stemming from or owned by that central block that we're not using a system block?
Is that a stereotype for that other element?
You could use a system block for that.
That's fine if you want to do that.
One of these had cameo on it a few minutes ago.
You may have to reload it.
So we're here.
And so let's just go back and put this in the right place.
If I go back to my top level electron microscope model.
If their virtual machine will wake up.
Okay, there we go.
So we're going to go inside the logical model here.
And create a package called subsystems.
By the way, is it too early in the morning for lab for you guys?
Nope, I've already been doing some modeling this morning.
So no big deal.
Okay.
So I'm going to make a package called subsystems.
And I like to use this show inner elements list.
So now what you see is I'm starting to flesh out, you know, the pieces of the model here.
So I'm going to make a BDD inside here.
Call it subsystems.
And so this is 2024.
There used to be, I think, a little drop down here that let me use the subsystem stereotype.
I'm not going to worry about the stereotypes for this morning.
So I'm just going to go make, what do I got, 4, 8, 11 blocks on here.
And so we'll turn that off.
Again, I was using this trick yesterday.
If you don't know it yet, I'll kind of remind you of it.
So you can hit that little make preferred size and then this fit to window.
And that gives you kind of a nice zoomed in view.
So I'm going to just name all my blocks.
I'm not going to worry that they don't have.
Actually, let me see if I go to refactor this.
Yeah, I can do it this way.
Okay.
So we could put the subsystem stereotype on there that way.
And we can make this one a system block.
I can refactor that into more specific system.
And you'll notice, by the way, that chat GPT, when it gave me my response,
actually listed out the main parts in here.
So what you see on those blocks, the parts that are showing are actually directly out of the chat GPT response.
So AI gives you quite a lot of information and you may have to refine all of that.
Also, these labels, if you like them, they're the role names.
You can keep them.
I don't like them.
I find that they clutter up my my diagram.
They also get out of sync.
Somebody changes something and they don't change the part name.
I'm sorry.
Those part names also get out of sync.
Somebody changes, you know, X to a Y, but then the part name is still X.
And then you have like, wait, wait, is it an X or a Y?
You know, the classifier name and the part name don't agree.
Oh, yeah.
The the role name.
You mean?
Yeah.
And we'll make these subsystems.
And, you know, is it really important that we call these subsystems?
Maybe.
Probably not if we're assigning a stereo type subsystem.
Yeah, I mean, so you can do that or not.
You can also probably do it this way.
Never mind.
But it might be important if someone's reading this diagram, you know,
I mean, especially we've got subsystem in the name of all the blocks.
You know.
But is it good form?
Yeah, you could say it's probably good form.
And also, when you see something that has an and in it,
that's probably two subsystems, right?
It's probably control subsystem and a separate subsystem for UI subsystem.
But for the moment, we can leave it like that.
Okay.
I always have trouble with these menus that pull off to the
left and right simultaneously.
Cover up my messy desktop here.
And I would say for right now where we're at with this lab,
don't bother putting the parts on these subsystems yet,
because we're going to go decompose one or two of them.
And that's really when you would get them.
So while we're diagramming what I'll point out is that everything we did
yesterday was kind of in the conceptual space.
But once you start talking about subsystems,
you're moving from the problem space into the solution space.
So you can also see why I'm anxiously waiting for one of these
subsystems.
So the true vision of AI assisted MVSE hasn't quite been realized yet
because the tools aren't quite up with the concept.
Because this drawing that we're doing right at the moment
isn't really adding a lot of value beyond what Chat GPT told me.
Look at that.
It doesn't give you the subsystem option to paste in there now in 2024.
Yeah, that's why I'm doing it with the refactor menu.
Right. Well, I was just making the list and I was pasting the list in there.
But when I use the 2022x, it gives me the option for subsystems.
In 2024 it does not.
Oh, so you actually are doing this a different way.
You're taking a list out of the Chat GPT response
and then saying you're copying that list and say now make blocks out of these.
Yep, yeah, you just copy any list.
It can be in any format for the most part.
You just copy it and hit paste.
You can paste it in there and choose what element type you want to paste it as.
Interesting.
I'm in the habit of drawing my diagrams.
I should probably take a page out of your book.
And what else can I do to these to make it look a little better?
I can make them all the same width.
All right, so I'm going to save this.
Let me see if I can snoop on the three of you and see where you're all at.
Oops, I got my same.
Elena, are you still with us?
Yeah.
Somehow I'm not seeing your screen with.
Yes, you are.
It's on the top right corner.
Oh, there you are.
I thought that was one.
So yeah, OK, good.
So we're almost we're almost done.
Anybody want me to wait before I move on with the lecture?
Looks like everybody's almost done.
I will continue if you want me to pause, speak up.
All right.
So the next thing that we're going to do is we're going to ask a I.
To tell us the interfaces that go across subsystems.
And so there's the prompt that I used.
And there is at least the first part of the response that I got.
And so next what we're going to do is we're going to make another diagram with a bunch of interface blocks on it.
And so are you all ready for me to move on to making this diagram?
Yes.
OK.
So again, this goes back on my other screen.
And it's like I have this open twice.
All right.
So now in my subsystems.
We're in my logical model package.
I'm going to make another package.
I'm going to call it interface blocks.
And I'm going to make a BDD inside of it.
And just going into where a lot of time gets spent.
Debugging item flow violations is that it's a very common practice.
That I've seen is that people don't do this step.
Before they start trying to do their I.B.D.s.
And in my experience, if you don't do this.
Before you do your I.B.D.s.
You get into a big time world of hurt in trying to put the item flows on your I.B.D.s.
It always gets screwed up if you don't do this step first.
So I always do it first.
This is one of those pain free tricks.
You have less pain.
If you define your interfaces before you start trying to put item flows on it.
So if you don't know how to get flow properties on your interface blocks.
Let me show you how to do that.
This little create element circle is very useful.
So I want to create flow properties.
So E-beam output and the type of that.
The direction of that is going to be out.
And then this interface block is called myElectronGun.
So you don't have to use this symbol.
Not everybody likes it or this style.
But I like to name my interface blocks with a lowercase I.
That in addition to this stereotype tells me that this is the ElectronGun interface.
You can spell out ElectronGun interface if you prefer that.
I don't really care.
But I use this convention.
It kind of works for me.
And then this little, once you've created an element inside here using the little black circle.
If you use the little white one.
It will create another one of the same type.
And I think what you're probably seeing now is that this goes a lot faster when AI tells you the answer first.
It's a lot more work to figure out all these interfaces.
If you're not getting the answers out of AI.
It's just really faster to do it this way.
And it feels almost like cheating, right?
Because you're kind of copying down the answers.
And maybe it is cheating.
But if AI can help you cheat, then you can go faster.
And of course, you always have to check what AI is telling you.
So you don't take it as possibly.
I think that's it for this video.
Thank you so much for watching.
I hope you enjoyed it.
I'll see you in the next video.
Bye!
Bye!
Bye!
Bye!
Bye!
Bye!
Bye!
Bye!
So hopefully you're starting to get a sense for how much labor savings comes out of asking AI to define this for you.
If you're just trying to think of all these out of the blue yourself, it takes a while.
There's a fair amount of detail in here.
And again, it may not be perfect, but it's not a bad place to start.
So we've been at this an hour and 10 minutes.
And I would say when you're done with this diagram, it's probably a good time for a break.
Daniel, I see you're still working.
Oh, no, I already completed the diagram.
I'm just completing every twice.
I have it on my first computer end.
Oh, you're doing it.
You're doing it twice.
Well, so why don't we come back at 11.25?
How about that?
And we'll put in the chat.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
All right, everybody back.
Any issues, questions, comments, anything like that?
If not, we're going to just keep going.
Okay.
So the approach that we're following is basically
Okay.
First, identify all the subsystems.
Next, identify the interfaces between those subsystems.
And now we're going to go create a bunch of signals.
So on an interface block, you have flow properties and you have signals.
And so what we're going to do next is go ahead and create the signals.
I'm not sure if we're actually going to use these signals.
Some of them, I think, may actually replace some of the flow properties that we put on there.
But for now, we're just going to go make all these signals.
So that's going to be the next exercise.
So over here under logical model, we're going to create a package.
Signals.
We'll create a DVD in here.
And I think the way I did this was I put them all on as flow properties first.
And then I probably redundantly asked AI to create signals.
So this may be a little bit redundant, but when you make an interface block, you have the choice of putting flow properties or signal receptions on your blocks.
And the flow properties have the direction in out.
The signals don't.
So we're going to make a whole bunch of these signals.
How many? 5, 10, 14, 18, 22.
Just make about 20 of them and see how far we get.
There.
Okay.
Okay.
Okay.
Noticing that some of these may be redundant.
Some of the flow properties that we put on there, in which case you can pick, you can delete the flow property and replace it with a signal reception.
But it kind of just sort of reinforces that you should always check what AI is telling you.
Certainly not all redundant.
Okay.
Okay.
Okay.
Daniel, where are you at?
So why don't you raise your hand?
When you're ready for me to move on to IBDs.
So I don't have like an actual lecture on how to draw IBDs in the PowerPoint.
But I'm gonna kind of explain it to you as we do the lab here.
And what I hope to show you is an IBD with no item flow violations.
Because if you, if you do this stuff in the right sequence, you can avoid a lot of the pain points.
And that's what I'm hoping to show here.
Okay.
Daniel, are you still with us? Did you get called to a meeting or something?
Nope, I'm here.
Do you have the signals done?
I will in just a second.
Okay.
So while you're still working, is there anybody here who's brand new to IBDs and hasn't done one before?
I'm gonna go.
Okay.
So I see you're putting them all on the same diagram, the signals and the flow properties.
I might put them on separate diagrams, but that's okay if you want to do that.
Probably a little bit more maintainable if you have your signals and your flow properties in separate packages, but that's fine if you want to do that.
Elena, are you ready to go on to IBDs?
Okay.
So everybody ready?
Then here's what we're going to do next.
So I'll do a little bit of theory discussion on IBDs.
I'm kind of going to assume you mostly all know what they are already, but what you show on an IBD is the interfaces, and in this case, it's interfaces across subsystems.
And so you can put lots and lots of stuff on an IBD, and the more stuff you put on it, the more difficult it becomes to read.
So something that I consider to be good practice is to make different IBDs to show different aspects of the interfaces you're developing.
So in the interest of time, we're only going to do one, and the one that we're going to do is basically to show power coming out of the power supply and feeding into all the other subsystems.
And we're going to show that using the iPower interface.
And so we're going to be adding proxy ports to all these other subsystems.
We're going to type the proxy port with the name of the interface block, iPower, and then we're going to show the actual power distribution flowing across those interfaces.
That make sense to everybody?
Yes.
Yep.
All right.
So how are we going to do that?
We're going to go back to our subsystem diagrams.
You know, looking at this again, it's been a while since I looked at this.
I think some of these signals are the types on the flow properties.
And we maybe need, we might need to go back and add those types, but we can leave them type free for the moment.
So how do we make this IBD?
Again, if this is new to anybody seeing it for the first time, please speak up.
But we're going to go to our BDD, our subsystem BDD, and then we're going to right click on the system block.
And we're going to say create diagram.
And it's going to be a SysML internal block diagram.
Now when we do that, we get this dialog.
And it's going to show all the subsystems that we have that we can put on this IBD.
So I'm just going to say OK.
And what I get is I get my subsystem diagram.
Now we haven't gone and put the parts in the power supply yet.
So let's just not worry about that for the moment.
But I put my power supply on the left.
And I'm going to take all my other subsystems and put them over on the right.
I'll line them all up.
So we'll get a little zoomed in view.
And so what we decided to do, or what I decided to do when I made this example, is to only show power on here.
Because with so many subsystems, if we start trying to show all the different flow properties across all the different interfaces, it's going to really become hard to see.
So I'm going to now go put proxy ports on all of these subsystems.
And what I'm going to do with my sticky button, which I like to draw fast.
So I'm going to put proxy ports on all of these.
And then I'll line these up on the edge.
Now the next thing I'm going to do, so I'm going to call this one power out.
I'm going to call all of these power in.
I'm just going to copy that name.
My command keys don't work.
So when you use ports, proxy ports, and most of the time you're going to use proxy ports.
The type of the proxy port is an interface block.
So the interface block that's going to type all these proxy ports, not surprisingly, is going to be the iPower interface.
So when I drop iPower on here, it is going to type those interface blocks.
And you can kind of immediately see that I have a problem with direction here.
So I don't know if you all know about port conjugation or not, but the way you fix this direction problem
is you check the is conjugated box.
And then you see this little tilde symbol.
So what port conjugation means, if you think of it, any interface has kind of a sender and a receiver.
And you usually write your interface blocks.
You define your interface blocks from the perspective of the sender.
So if I look at my interface block, all these flow properties are coming out of the interface block.
That's the perspective of the sender.
And when I'm receiving the power in all my different subsystems,
I have to switch the direction of the interface from sender to receiver.
And the way you switch that is by opening the port specification and checking the is conjugated box.
So we'll connect the first one here.
So this one's going in the right direction and all these are incorrect.
So I can click this port and interface it to there.
And I'm OK.
But if I do that, you see that my cameo tool gives me an error.
And so if you haven't seen these errors, you can click on this little red X here
and say it'll tell you it's an incompatible flow and it'll give you some possible suggestions.
So what I have to do is reverse the direction of the support power in and that just conjugated the ports.
If I open this one up now, now is conjugated is true.
So I can either go through and set is conjugated or I can kind of just wire them up like this.
And when I get rid of the red ink, it'll conjugate all the ports.
So, again, I can do that and say reverse direction of the port power in.
Reverse direction of the port power in.
And I'm pretty much good to go at this point.
And so this is one of those time consuming errors that happens all the time when you draw IBDs.
And the technique that I'm attempting to teach you here is to always define your interface blocks before you start drawing IBDs and before you start putting item flows.
Oops, something wrong on that one.
Okay.
Okay.
And it looks like I screwed it up a couple times.
Okay.
Okay.
Accidentally deleted my port.
Okay.
And then finally, to put the item flows on here, I just take my flow property.
Oh, I don't know.
Okay.
Okay.
That's interesting. Maybe I have to put a type.
Where do I want to go? Interface blocks.
Signal.
So if you haven't seen item flow manager before,
item flow manager is a very confusing user interface compared to most things in cameo.
But what you have to check when you put the item flow on there is that it's going in the right direction.
So I'm going from the power supply to the image processing subsystem.
And when I say finish, it will put that on there.
How did you do that? What did you do?
Okay. So the first thing that I did.
And I now realize remind myself why I had to have all those signals defined.
So when I tried to drop the flow property onto the connector,
and the flow property didn't have a type on it, cameo wouldn't let me do it.
Okay. So the first thing I did is I took the signal power distribution and I dropped it on this outflow property on iPower.
Okay. And then the next thing that I did was I took this flow property power and I dropped it on my connector.
And I said set as item flow.
And I click finish.
And if I would have drawn these a little bit differently where this was off of that,
then you can kind of see that it's putting the item flow on the right one.
Now I'll show you, I'm going to make a mistake intentionally and show you what happens.
So I'm going to drop it on that connector.
But this time I'm going to change its direction to be backwards.
And as soon as I do that, it should light up in red.
Okay.
And now if I go here, it's going to say.
Okay, I see that one.
I just, when you edited the one on the interface, you edited the iPower interface block.
That's what I think I'm missing.
Yeah, so what I did, when I created these flow properties, they were untyped.
Okay.
And I typed it with the signal that we created on the signal diagram.
So the signal is called power distribution.
And I have a flow property called PWR.
Now it has a type on it called power distribution.
And once I put the type on it, that's when Cameo let me drop the item flow onto the diagram.
How did you type it?
I typed it by, here let me do another one.
So we have a signal that we make called power regulation, right?
Yes, okay, yeah.
And so how I typed it was I dropped the signal onto the flow property and said change type.
And that's how all those types got on all those interface blocks.
And then once my flow property is typed, then I can put it on there.
Now how do I get rid of this?
Now we got to go look at the item flow manager.
So if you haven't used item flow manager, it is here.
And I've got this item flow that's basically wrong.
And one of the confusing things about this interface for item flow manager is that the delete button is kind of hiding up here.
So I want to delete my incorrect item flow.
Now I can close item flow manager.
And now I can go back and grab power.
Drop it on there.
And the direction is correct.
And I can finish it.
So if you've ever spent much time doing IBDs,
your experience may be that this IBD kind of got put together a lot more smoothly and with a lot less red ink than what you've seen before.
If you're already doing your IBDs and don't have any trouble with item flow manager, then I will say congratulations.
Your experience may not be typical.
But if you do them this way, where you define the flow properties and the signals and the interface blocks first,
then getting your item flows on here should just be a question of dragging the flow property onto the connector.
And checking the direction.
And it should work out maybe smoother than what you've seen before.
I hope so.
So my point is there is a sequence of steps that you can follow that will keep you out of trouble with item flow manager.
And personally, for me, the less I have to use item flow manager, the happier I am because I find that it's
user interface is not much fun.
I actually did these in exactly the wrong order here.
So I'm going to reorder my diagram a little bit.
I think the Cameo user interface is challenging everywhere.
Well, it is challenging everywhere.
Two of the most challenging places are requirement numbering and item flow manager.
Having taught Cameo for quite a while now, everybody gets stuck with item flow violations.
Everybody gets stuck with requirement numbering.
It's just kind of how it is.
But really the only red ink I got here was trying to show you the mistakes that you're typically going to get.
I didn't get lots of other red ink.
And having completed this IBD this smoothly is something that personally I'm very happy about.
And the tricks are define your interface blocks first, define your flow properties, define your signals, and then do your IBDs.
Where people get in trouble with IBDs is very much just trying to add item flows.
I can take this connector and I can go here and say new item flow and then pick something from somewhere
and I'm going to get in huge trouble if I try to do it.
So I never make item flows by clicking here and using new item flow.
I always check my directions on my ports carefully, check my directions on my flow properties carefully,
and then just drag the flow property onto the connector.
And it usually works pretty smoothly if you do it that way.
Now, of course, we cheated, right?
And how we cheated was that before we tried to draw this, we asked AI, tell me the interfaces,
show me the interface blocks, show me the flow properties on the interface blocks,
make the signals which type those flow properties,
and I'm not going to make you go back and type all the flow properties on here for your lab.
But if you do it that way, define your interface blocks first, then define your flow properties,
define your signals to type the flow properties,
then making the IBD becomes much easier and you have a lot less red ink to fight.
So let me snoop on you guys and see how you all did or are doing.
So, yeah.
Look at that.
I see three IBDs and no red ink.
I'm very happy about that.
Because when I have taught this class, not this class, but taught other system L classes before,
I always spend like half the lab debugging item flow violations.
So when I talk about writing a book on pain-free MBSC,
there's going to be a whole section on what you just did,
which is how to do all this and not get trapped in all the red ink.
You have to understand the relationship between a port and interface block,
a flow property, and a signal.
And once you understand all that, you can do these IBDs without red ink.
Sound all right, everybody?
Okay, so it is 12.13.
Seems like a good time for lunch to me.
Any objections?
So let's come back at 1.15 and we'll continue going through logical architecture.
Is all this stuff making sense as I do it?
Because I didn't put lots of tutorial slides on here's what an IBD is and try to explain it that way.
I just sort of explained it in the lab.
All right, well, then we will reconvene in an hour.
And if any questions occur to you over the lunch break, save them up.
And we'll talk about them then.
Thank you.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Everybody's here in the meeting.
All right.
So before we continue with logical architecture, which as you're seeing is a pretty big module in this course.
Any questions about anything we did this morning?
That means it's all crystal clear, right?
I hope so, actually, because this is meant to be kind of a very simple, easy to follow, straightforward process that steers you around the time and schedule.
All right.
So just to kind of review really quickly.
We crossed the boundary between conceptual modeling and architecture.
When we started talking about subsystems.
And then in addition to listing the subsystems, we started defining interfaces between subsystems.
Signals needed to type the flow properties on the interfaces.
And then I'd be these to show those signals crossing the interfaces.
Next, so we're still kind of working at the top level of the electron microscope now.
And the next thing we want to do is a top level state machine that connects the subsystems.
And I basically got chat GPT to describe this state machine with the prompt that you see in orange, which says describe the top level state machine that connects all the subsystems of the SEM.
And chat GPT told me what you see in white here.
It's going to initialize from initialization.
It goes into idle.
Excuse me.
Are you sure?
Oh, I'm very sorry.
Thank you for.
Thank you for that.
Let me get back to that.
Apparently, I'm brain dead after lunch.
So let me go through that again while sharing the screen.
So we started by identifying all the subsystems.
Then we started identifying interfaces and defining interface blocks.
Those interface blocks have flow properties and the flow properties are typed by signals.
And here are the signals.
And then once we put that structure in place with the interfaces being defined, then it's much simpler to draw our IVDs and show the interfaces.
And I think where a lot of people get in trouble is that they try to make those interfaces up as they're doing the IVDs instead of defining their interfaces first.
And that causes a lot of trouble.
Next, what we're going to talk about is state machines.
And so I asked AI to give me the top level state machine that connects all those subsystems.
And the response I got was we start out by initializing and that sets everything up and we go into idle.
And then we can transition into different operations from the idle state, really different states from the idle state.
When we're scanning the image, we go into imaging.
After imaging, we go to image processing.
After image processing, we're going to analyze the images that are produced.
And after they're analyzed, we can generate reports.
And then we can go back to idle.
So I was particularly interested in both imaging and stage control because later chapters in the book are going to do things with those two subsystems.
And so I asked it to describe substates within those two higher level states.
And I got this result.
And, you know, you can if you start looking at SysML version two language model, you'll realize that the gap between what's being produced here and what's in a SysML version two language model is really pretty small.
And it's just the question. It's all the same information.
It's just a question of changing the format of it to basically generate the state machine in SysML version two.
But we didn't have that available when I was writing the book.
And so manually, I basically constructed this state machine from what AI gave me.
And what we are now going to do is you're going to draw the state machine and then we're going to simulate it.
And just I'll give you a really, really quick review on state machine syntax and notation.
And is anybody new to state machines? Anybody hasn't seen a state machine before or hasn't built one?
I have not.
Okay.
So anybody else?
All right.
So the yellow bubbles on here are the round cornered rectangles that are in a column represent states of the system.
And what you can see, because we can have states within states, is that we can have hierarchical state machines with nesting in them.
And there's a bunch of different ways to do nested states. I kind of kept it pretty simple in this example.
But the black dot or the black circles that you see are the initial state.
And you'll notice that when we're talking about substates, each substate has an initial state.
And then the little bullseye, black and white bullseye looking state is the final state.
And so for our substates, we have both initial states and final states of the substate.
When you hit the final state of a substate, like this one here, then what you do is you follow the unlabeled transition out of that substate.
And the transitions take you from state to state.
And what triggers a state transition is basically a signal.
So I'm going to guess that we have a signal called position stage.
Let me go back and look, actually, just to make sure.
So do we have a signal called position stage?
Yes, we do.
So right up here in the top center is the signal called position stage.
And when you draw a state machine, you can just drop that signal right on the transition.
So that, you know, and if you don't have the signal defined, you can create new signals by just typing, basically draw the transition.
And without clicking anything, just type the name of the transition, what you think is the name, but it's actually the signal name and not the transition name.
What else?
So state machines get more complex than this.
You can put on any state what's called entry behavior, exit behavior and do behavior.
We're not going to do that on this particular state machine.
Any questions?
All right, so we're going to get ready to draw this state machine in cameo then.
And I will draw it with you.
So here we are on the desktop again.
And I think this is my desktop, which it is.
So at this point, if you haven't used this, used cameo very much before, you can start to see that I'm getting to have a lot of tabs open.
And it sort of starts to get a little hard to follow, which is open.
And so there's kind of an easy thing you can do, which is to just close tabs.
So I closed all of them.
And now I'm just going to close some stuff up here, go back to my top level electron microscope diagram.
And what we want to do next is make a package in our logical model that I'm going to call top level state machine.
So I'm going to do this here.
I'm going to create a package.
I'm going to call it top level state machine.
And now I'm going to create a diagram in my top level state machine, which is a sysml state machine diagram.
Now you'll notice that when you create a state machine in sysml, it automatically gives you the initial state and the first state that you transition into.
And I think I'm not going to bother using composite states.
I'm just going to make all these simple states.
I don't think I'll get in trouble by doing that.
I may be wrong, but I don't think I will.
I've heard that that can cause problems, but I've not fleshed out how that causes a problem.
Well, it might cause a problem when we're simulating.
But I kind of don't think so.
So there's lots of different ways to do substates.
But I'm going to just start with just making everything a simple state, and we'll see if I get in trouble.
I'm going to introduce you to the cameo simulator at this point as well.
So I'm just going to make another state here and a little bit bigger state over here.
And I'm going to put my state final over there.
And then we're going to do this top level composite state here.
And then we'll simulate it and we'll see if we get in any trouble.
So we can label these.
This is initialization.
That's error.
And then we're going to wire these up with a couple transitions.
Now the question is, do I have a signal called initialization error?
If you haven't used the little magnifying glass here.
So it looks like I don't.
When we did our signals before, we didn't make one for initialization error.
So let me show you how to do that.
So this search tool here is really useful.
And that's this little search tool there.
So to label this transition initialization error, and you want to maybe watch this carefully, I select the transition.
And then without touching anything else, I type initialization error.
And what you can see over here in the containment tree is that it made a signal for me called initialization error.
So the quickest way to create signals in Cameo is actually to just label a transition.
So here's initialization error.
If I don't get the initialization error, I'm going to get initialization complete.
And I didn't notice that.
I'll just check again.
Do I have initialization complete?
No, I don't.
So I'm just going to select that and start typing.
Initialization complete.
And then this state is called system ready.
It's easier to read.
And now I have a state called stage control.
And I think now we're going to get to a signal that we do have.
So I'm going to draw a transition from system ready into stage control.
And again, I'm going to check.
And here I have a signal called position state.
So I'm going to take that signal and drop it on that transition.
So in all these cases, I want to point something out to you.
If I open this transition, what the name of this transition is blank.
When I typed the name of that signal, it created a signal element called initialization error.
And then it created the trigger on the transition and said it's a type signal event and the signal is initialization error.
So I don't ever put anything in the name field on these transitions.
If you like double click on it, like if you open the specification and type the signal name here, it's not going to work.
So just make sure you're you're clear about that.
The syntax on a state transition is you have trigger, guard and effect.
The trigger is generally a signal. It could be a different type of event.
So types of events that it could be are a change event or a time event.
But in this case, we want a signal event, and that's the most typical one.
The guard is a Boolean condition that gets specified here.
And then the effect is usually going to be an activity.
So what that means is that as this transition is firing, it can actually launch an activity that we've identified on an activity diagram.
All right, so we're going to put three substates in here.
And then within this stage control state, we're going to put an initial.
And a final.
And then we're going to drop a transition back to system ready.
Out of here.
And then we're going to connect these.
So technically speaking, this initial state is not really a state, but it is something called a pseudo state.
And the difference between a pseudo state and a regular state is that you can never rest in a pseudo state.
You always have to follow the transition out of it as soon as you enter it.
So my substates here are idle, moving.
And stopping. And again, if you remember our.
Let's just go back and look at the domain model to remind you what the stage is.
So.
We finally decided to call it sample stage instead of just stage.
But the stage sits inside the sample chamber.
And the sample sits on top of the stage.
And the stage is going to move back and forth because it has.
Motors in it as an X motor and a Y motor.
We haven't specified those yet.
But we will.
OK, so you can call it sample stage or just call it stage.
But the stage is where we put our sample and then we move the stage underneath the electron.
So we have position stage coming in here.
Now we have move stage and we want to check if we have that that signal already.
And we do not have that signal.
So we're going to create it.
And then we have another.
Transition called position reached.
And we don't have that.
So the reason we don't have these signals yet.
Is that when we asked for.
All the signals at the top level, we didn't get the signals down inside the subsystems yet.
So this thing, position reached.
Is really a signal that's going to exist.
Inside the stage subsystem.
All right.
So is everybody with me where I am on this diagram now?
Because the next thing I'm going to do is simulate it.
I got a yes from Mark.
I had dropped my signals.
I'm building everything twice.
OK.
Maybe when you build it twice, build it on the virtual machine first.
Instead of on your local machine first.
Are you OK if I start simulating this now?
OK.
All right.
So if you haven't used.
Well, first of all, is there anyone who has not used the cameo simulator?
OK.
So this is going to be your introduction to this.
All right.
So you should have.
This little triangle button on the top of this little ribbon.
That is your simulator button.
So when you click it, you get this other window and there's a lot of detail.
To be had in in this simulation window.
And this isn't the only state machine we're going to do.
But a couple of things you should know.
One is.
Somebody put something in the chat.
The RV.
You're right back.
OK.
Well, I'm going to hope that he knows how to use a simulator.
I think he probably does.
So one is you have a.
A little.
Date myself and say VCR control panel more like a DVD control panel here.
And this little play button starts the simulator and the little red square stops.
The other thing that you'll find is that there's this thing called the trigger menu.
And what's on that trigger menu is all the signals.
That we are using on this statement.
And we're going to give those signals to step through.
Simulating the statement.
Hey, so I'm going to there's a bunch of other stuff here.
Console variables.
All kinds of stuff that we're not going to worry about right now.
But we're going to start this simulation.
And what you see is that when you start the simulator.
It starts lighting things up.
And so this state that you see in red, that's not an error.
That's just where we are in the state machine.
So what signal do we want to give it?
We want to give it initialization complete.
And watch it go into the ready state.
So when I give it initialization complete.
Now I've advanced.
Excuse me.
I've advanced to ready.
And next we want to go into stage control.
So I'm going to give it position stage.
And now what you see is that it's gone into the stage control state.
And it's dived in, dove in.
Drilled down into the internal details of this state.
And now we're looking at the substates.
So now we're in stage control but our stage is idle.
We're going to move the stage.
And now the stage is moving.
And while the stage is moving, it's going to check if it's at its desired location or not.
And if it is, it's going to send back a signal that says the position has been reached.
In which case we stop.
We get to the state final in the substate and transition right back to the system ready state.
So that's your first quick introduction to the simulator.
Elena, how did you do?
Did everything simulate okay?
Good.
All right.
So we're going to stop the simulation now and finish up the state machine.
And I'm not going to narrate this every step of the way.
I'm just going to draw it.
And then if you have questions, just shout out.
In this case, I have a signal called scan and I'm going to use that instead of scan sample.
You want to be careful not to redundantly create.
I have a question.
Yes.
If you go and you start just like naming that transition and that already exists, it won't select it.
It will just create a redundant one.
I'm actually not positive.
You can try it.
What was the question again?
If you start typing scan here and there's already a scan sample, will it search for it, find it and pop it up?
I think you have to search first.
But I'm not 100 percent positive.
I think it will create a scan.
I think it automatically sets a new signal to scan.
Yeah, that's what I think, too.
Sure, yes, it already exists, but I'm just asking if it doesn't already exist.
But I'm asking if it does already exist.
It doesn't let you select the one that's not looking to see if something already exists and selects that.
I think you're correct and it doesn't.
Due to naming conflicts, it might cause an issue because if you've already got something called scan and it's a signal,
you're trying to identify, you're trying to name another thing the exact same thing as a signal.
I think with signals, it might cause an issue.
It might grab the previous one that you created.
Yeah, I'm just not sure.
You'll have to test it, Elena.
I'm not certain of the answer and so the safe thing to do is test it.
But from a best practice standpoint, before you type a signal name, it's a good idea to search for it up here.
The way I've been doing it.
So I've got my top level states there.
I'm going to add one of those.
Sorry, sometimes I mumble to myself.
I'm probably very distracted.
And you got a hand up.
Is that a question or you're done?
I'm done.
All right.
And it all simulates.
Oh, well, let's see.
Yep, all good.
Cool.
Okay.
Again, you can kind of see why I'm really looking forward to the day when I can just ask Chat GPT to go create my state machine.
Because there's a fair amount of work involved in drawing these.
And it looks like I haven't put any signals on those.
So and you'll see when you simulate it, if you don't put any triggers on these transitions, the simulator will just zip right through them.
Without stopping.
All right.
So I'm going to go simulate mine now.
First, I'm going to save it.
Using now.
So here's where all the years since I took high school grammar fail me.
So these aren't exactly nouns.
They're not things.
And they're not exactly verbs.
And if you ask me what part of speech they are, I'm going to be stumped for an answer.
Probably.
Yeah.
Well, what they represent is they represent states that the system can be.
So it's either waiting for something or doing something.
And.
Yeah, I don't know that I would say that it's necessarily a verb of anything.
I mean, think about some of the most simple ones.
Just, you know, you could have a power on state.
So there's not one answer for that.
It's just going to be dependent on your system.
So I'm going to cheat and ask Google here on my phone.
Like what grammatically, what part of what kind of element is the word analyze?
What part of speech is the word analyzing?
It says it's a verb.
All right.
Let me try another one.
What part of speech is the word completed?
What part of speech is the word completed?
Completed is the past participle of the verb complete.
So it is considered a verb when used in a sentence.
So I guess they're kind of verbs.
You know, moving is a verb.
Stopping is a verb.
So, you know, but usually with state machines, you don't really think so much about nouns and verbs.
They are states that the system can be in.
I guess most of the time, like ready, you know, what is ready?
I don't know.
So it's a good question.
And it's been way too many years since I took English in high school.
I apologize.
But let me check.
How's everybody doing with getting these state machines to simulate here?
Elena, it looks like you're still diagramming.
I am.
Okay.
So we'll wait a minute or two and let you get that done and simulate it.
But I guess while you're doing that, I'll kind of go reinforce a little bit what this approach is that I'm teaching you,
the domain driven logical architecture approach.
And it's basically to do everything at the top level first, going across the various subsystems.
And then when you get all that done the way you want it, then you start diving down into each subsystem in turn.
And you kind of repeat the same process, but it's within the subsystem instead of across the subsystem.
And in parallel with why you're doing this, you're probably discovering new requirements.
And you're probably going to have subsystem level requirements as well as the system level requirements.
So all the while that you're kind of modeling what the system does,
the basic approach is to get it right at the top level first.
And then you dive down to each subsystem in turn and get that right.
And of course, if you're working on a team, once you get the top level stuff correct,
then you can task different people on the team with going down into each subsystem.
Right. So does that all make sense just from a philosophical standpoint?
Yeah. Another beautiful thing is it's just a few boxes and lines,
but it's so good at making clear when things happen.
Imaging only happens after system ready.
And these are the three things you do in imaging at the higher level.
Yeah, me too. They're really powerful.
And then somewhere they localize the code quite nicely too.
Yeah, in fact, that may be, well, not yet.
We've still got some more to go.
But you can, and this is a really cool thing which you may want to try,
is just save that state machine as an image.
Go drop it onto chat GPT and say, write me the C++ code for a microcontroller
and watch it go because it's really cool.
In fact, this was the diagram.
I was working with Brian on a Zoom call and I had done this state machine,
which doing it the first time took a little bit of work to transcribe what chat GPT did.
Once you see the answer, it's pretty quick to draw it.
But it took a little while to get this, to simulate correctly based on what AI gave me.
But then from there, when you just say, write the code for this, boom, done.
You know, I just started playing with chat GPT as of yesterday and today.
And I just tried playing around with it after I saw you generate some images.
And I tried to get it to generate an image and I don't know, I kept running into an error or something
because I asked it to generate an image for my family vacation, which is me and my wife and three daughters.
We're getting ready to go to Columbia.
I was like, hey, show me an image of a man, a woman and their three daughters.
And for some reason, I don't know if it's some kind of politically correct thing or something.
It kept sticking a little boy in there.
And I'm like, please replace the little boy with a little girl.
And it said, yes, this is this.
And it could not get rid of the little boy.
And I'm like, add a little boy or something and then add a little girl.
I don't know if that's like a common thing or that's just me.
Well, that's called an AI hallucination.
And they do happen fairly frequently.
They happen a little more frequently with image generation because with AI, there's actually like a creativity setting.
And when it's trying to be creative, it has more latitude to change things.
But there is a whole political correct wokeness about chat GPT.
And this is going to vary from different AI models.
You know, Grok is less woke than chat GPT is.
It has to do a lot with, you know, who owns the company that built the AI package.
I tried so many times to get it to just remove the little boy and it would not do it.
And I'm just like, I don't have a little boy.
I'd love to have one with a little image, you know, just like that.
I told it the first time.
I was like, oh, it's perfect.
But it gave a mom, a dad and two little girls and a little boy.
And I'm like, that's a perfect image.
I love it.
It's in the place where I'm going.
You know, the exact place is actually like an image of like the amusement park we're going down there.
And I was like, just please replace the little boy in the image with a little girl.
And it won't do it.
Yeah, I understand.
I actually made a video.
It's up on YouTube called Multimodal Hallucinations.
And I don't know if you guys follow baseball, but I live in Los Angeles and we have a kind of a superhuman ballplayer, Shohei Otani.
And I noticed last summer watching a Dodger game that Shohei holds his bat kind of like a samurai holds his sword, like kind of up like this, straight up and down.
And so I had to start generating images of Shohei and of a samurai.
And I tried to get the samurai and Shohei like the samurai standing behind Shohei in the same batting stance.
Shohei bats left handed.
And it kind of just started refusing.
It would always make the samurai in a right handed stance and not a left handed stance.
There was nothing I could do to stop it.
It was I made a whole video about it.
Why do you think that?
Well, okay.
At the next break, I'll go find my video and then I'll show it to you after the break.
But it basically got very confused between left handed and right handed.
It just like totally confused those concepts.
How are we doing, Elena? Are you done with your state machine? Does it simulate?
I'm done.
Cool.
All right.
So we're going to move on then.
So this particular slide deck has a lot of stuff in it.
There's like five or six different labs all rolled into logical architecture.
But architecture is complicated.
So that's why it's like that is because architecture is complex and difficult.
All right.
So now what we're going to try to do is illustrate this recursive subsystem decomposition,
which means we start taking the subsystems subsystems apart one at a time.
And then then kind of becomes lather, rinse and repeat.
You just do it once at the top level and then you do it at as many levels as you need to get down.
And what we're not doing just to be clear is what we're not doing is starting with one top level function and decomposing it into sub functions and sub sub functions.
That's just not in this process that I'm teaching you.
And so it goes back to the stop banging your head against the wall if it hurts when you do it right philosophy.
So what we're going to do now is we're going to go decompose the stage subsystem and we're going to go make this BDD.
And so if you guys are ready, we're going to do that in the lab.
Does anybody need a break before?
I would say let's get this BDD done and then take a break.
But if you guys need a break, let me know and we can take one now.
All right. Not hearing any requests for breaks.
Off we go into detailed BDD labs.
Save my model here.
Close up a couple of tabs.
And now inside subsystems.
What we're going to do is go into the.
I'm looking at the domain model.
Excuse me.
I want to go into subsystems and I want to look at the sample stage subsystem.
And what we're going to do now is we're going to make a child BDD right inside of this subsystem.
So I'm going to click on the block sample stage subsystem.
And I'm just going to go create a diagram in here, which is a BDD.
And then I always count how many of them I have to make.
You don't have to do all the click in and rename and click and rename.
Well, let's try this. I think I can probably just type it in
a note, right? And then just copy and paste it from the note.
So, let's try this your way. I always learn when I'm
teaching, so I'm happy to learn a new trick here.
So, I'm gonna just start typing the names
of these.
I
may never teach the same again after this.
Alright, so here they are all typed in
a note. And I'm gonna copy them.
I can't use my keyboard
to do copy, but I'll do that.
And then if I click on the diagram,
I can say paste.
Sorry, it's a
pain when your keyboard doesn't work.
I actually can't delete that thing now.
It's not in the containment
tree. So, I've selected the
every time I do that, it selects the whole
note.
Let's see if I just...
I've got
one note open, so I've got all the images there, so I just type out all
of the text there right next to the image. And then I just paste it in.
So, I'm copying it. Let me see if I can
find...
I'm a Mac guy,
so...
Did you open up OneNote for Windows there?
OneNote for Windows 10.
Oh, but I don't have a...
I don't have a Windows account.
Click on the Windows button and then type in
Word. If you just click on the button, then you start typing Word.
Yeah, WordPad.
Then Control V there.
Alright, I assume I have to
delimit it. I would say... I've not tried it like that, but yeah, usually
I put it as a list. Yeah, just like that.
This would probably be
faster if my keyboard worked.
Alright, so...
No, I'm on a Mac keyboard
and it's a Windows virtual machine.
That's the problem, right, is that...
Alright, so
I've copied these and now what you're saying
is if I go here... Just click there on the
diagram. Just click on the diagram and then there you go, Elements.
And then Block.
That's it. Well, that's pretty cool
actually. You can do the same thing with any of the properties
of the block. I just usually... So, I type out all the properties
and I paste them on the block.
Well...
Okay, I missed it. I think I was looking at it. So, after you have everything
copied, then you're right-clicking on the diagram?
Yeah, you can just click and say
Control V if you're on a PC, but on mine...
Yeah, that's cool.
So, I got X-Motor, Y-Motor,
X-Position Sensor,
X-Limits.
Yeah, it's funny because
I literally can't... Well, maybe I can.
Now,
I got rid of them.
Not being able to use your
control keys is kind of
a little bit frustrating, so I appreciate you
bearing with me here.
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
So, one thing that I just did is I converted my
move algorithm from a block into an activity.
And I'll show you in a
few minutes why I did that.
...
...
...
...
...
...
...
...
...
...
So, basically now instead of
having done a bunch of nested activity diagrams
to figure out what my functions are,
I'm just going to
add the operations to the blocks.
And
how you do that is you click this little button here
and say operation.
...
...
...
So, what you're doing is you're still uncovering all of your functions.
But you're just putting the functions
on the parts.
And I can add values here as well.
...
...
...
...
...
...
...
...
...
...
So, we don't miss any of the functions by doing it this way.
It's just, at least to me,
a lot more efficient than drawing all those
trees of activities.
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...                

on 2024-12-16

language: EN

                  WEBVTT
Alaina, you're looking good.
I'm gonna guess that this one is Mark.
And that this one is Daniel.
Yeah, that's Mark.
So, Daniel, I'm guessing that you are probably already done,
but doing this on your other computer.
Not hearing you very well.
Can you hear me now?
Yes.
Yeah, I already faced that diagram.
I'm just finishing up a second diagram now.
All right.
So you're just working ahead of us all.
Well, I think it's probably time for a break.
Let's make this a 10 minute break.
Because we got quite a bit to do.
So I'm going to stop sharing my screen.
And say back at 1110.
And we'll see you in a few minutes.
All right.
All right.
All right.
All right.
All right.
All right.
All right.
So, for those of you who are up for a challenge,
I have put the random number generator script that Brian gave me
and put into our model into the Zoom chat.
It's not really my expectation that any of you will get this simulation running today,
but you may exceed my expectations.
So I'm going to move on to our next diagram here.
Share my screen again.
And just so we're all on the same page.
We are going to now draw this simulation context BDD.
And I'm just going to make all these as clean blocks within this simulation package that we're creating.
So, just to continue then, in this SNR simulation package,
we're going to create a diagram.
It's going to be a BDD.
And we're going to call it simulation context diagram.
And we're going to put three, four, five, six regular blocks and two interface blocks on this diagram.
So, we're going to call this simulation context BDD.
And we're going to call this simulation context BDD.
You'll notice that we're using both generalization and composition
on this diagram.
And so, the preamplifier is an amplifier.
And the AMF3F preamplifier is a preamplifier.
And the sky, whatever it is, is an amplifier.
So, one of the differences between this BDD and the one that you drew yesterday
is that this one has the signal generator in it,
which is really only used for the simulation.
Also, you're going to notice that this relationship between the imaging subsystem
and the signal generator is a directed association, not a composition or a generalization.
What that means is that the signal generator is not really part of the imaging subsystem,
but it's used in the simulation.
So, I think that is all the blocks.
I think for these constraints on the BSED,
I think we can just drag and drop them over from the containment tree.
So, this is how the constraint blocks that you just drew before the break relate to the BSED.
These are all constraints on the BSED itself.
And then generate signal.
And generate noise.
Generate signal and sine wave.
I'm sorry. So, with the signal generator, what kind of connector is that?
That is a directed association, which is that one.
What do you mean that one? Okay, I see it now.
So, just understand that where you see constraints on this BDD,
you're looking for the constraint blocks that you just drew in the previous lab.
And then you just drag and drop them on here.
You don't want to enter new ones because you put all the equations,
all the constraint expressions in the other constraint blocks.
I wish my delete key worked.
Oh, and now here's something that I have to remember how to do.
Okay.
For the interface blocks, are those from what we created before? Are these new?
Just make new ones.
I am trying to remember how to show the inherited attributes and override them.
If you open the specification on the block, go to attributes on the left side there.
Attributes.
Try properties.
Yeah, that's right. Oh, there it is.
I was looking for those before.
So, thank you.
So, first thing I want to do is get these to display on my block.
And so I want to redefine these, and I want to put default values in them.
Okay.
So, thank you for reminding me how to do this, Daniel.
So, Elena, let me do this again so that you can see it.
I'm going to guess that you probably might not know this.
So, let me know when you're ready, Elena.
I'm ready.
Okay. So, you're going to open the specification for this AMF3F preamp.
Then you're going to go to properties.
And what you're going to see with this little tick mark, that means it's an inherited property.
So, it's reading that generalization relationship.
And because the AMF3F is a preamplifier and a preamplifier is an amplifier.
Basically, we inherit the attributes or the values of the parents of this.
And then we get to go redefine them.
So, if we click on the little caret here, we can say redefine.
And then it's going to put you in the type column, which is not what you want.
You're not changing the type.
We're going to give it a default value.
And this is going to be 0.7.
And where these values came from, where the 43 and the 0.7 came from,
are from the spec sheet of that AMF3F preamplifier component.
Got it.
And then when we specify these values here, when we enter them.
So, we're going to say gain colon db.
And then if I open the spec sheet here and I go to properties,
I can give them default values here.
So, 15.
So, that's how you get the default values on the value properties.
Awesome. Thanks.
Not having the delete key is really annoying.
So, just pretend that this block isn't here.
If I delete it out of the containment tree, then I got to create another one.
So, I don't want to do that.
I don't think it'll harm anything being on the diagram twice.
What interface blocks are typing the proxy ports that are on the BSED signal generator ports or blocks?
It looks like they are just simply typed as real.
And they're not being typed.
Never typed a proxy port as real before.
But if that's the case, I don't think you can do that right off because it's got to have flow prompt.
Well, so, on the BSED one, it's typed with IBSED.
Yep, I've got that one, but the other two there.
Yeah, they're just, they're kind of not proxy ports like we need on an IBD.
They're just proxy ports to use on the parametric diagram.
Right, and that's fine.
That's where I created it was on the parametric.
But it's going to have to have some kind of flow property associated with it to be able to generate that arrow to show whether something's coming in or coming out.
And I don't know how that's being generated right off.
What's flowing there?
Well, let's see if I can manage to do this.
I have a question after you're done with that.
All right, let me just try and do one of these here.
Yeah, I guess just don't worry about the direction, at least for now.
We'll see what happens on the parametric diagram.
But I do understand your question.
Elena, what's your question?
I think I figured it out.
Right, so when we're looking back at that AMF, looking in the properties, I didn't have my values added yet into that block.
So the ones with the carrot next to them are the ones that are inherited from being generalized to those other blocks.
So those we don't worry about, we create the value properties and then add that default value so that it can be applied specifically to that.
No, you don't recreate those values.                

on 2024-12-16