Modeling physical systems resources

[Medic]

Hi All,

I'm an expert in embedded systems development but new to UML.

I'm keen to learn about using Sparx to represent physical devices like washing machines, robots and other mechatronic devices.

The only Sparx example I found was the audio player and after a day of poking around the model I'm not sure where to start with my own machine.

Is there any step by step guides for using Sparx to describe physical systems?

Like: describe all your sensors, add them to the devices, describe their actions in classes, give each attributes. etc.

A workflow tutorial to go along with the audio player would be great!

All suggestions gratefully appreciated.

Thanks,

M.

[qwerty]

You should google for SysML since that is what is designed for your target systems (there are a couple of good reads out there). You can model SysML natively with a little effort for most ranges. Or you can opt for the SysML MDG which supports more sophisticated parts of the SysML language.

q.

[Eve]

You should google for SysML since that is what is designed for your target systems (there are a couple of good reads out there). You can model SysML natively with a little effort for most ranges. Or you can opt for the SysML MDG which supports more sophisticated parts of the SysML language.

q.

SysML support is available with the Systems Engineering or Corporate editions of EA, or any edition with a license for the MDG Technology for SysML. In the current version of EA I would recommend adding the license key for SysML, but not installing it. The add-in provides SysML 1.0 support and doesn't do anything else for you. Once SysML is licensed EA itself provides a choice of SysML versions 1.1 - 1.3.

[Medic]

Indeed, I was planning to use EA as my software folks are already using it for classes.

I understand that SysML and UML are basically the same idea with different diagrams and extensions to abstract the terminology into physical devices.

In my attempt I added notes and device blocks to the deployment view under components to describe my sensors etc. Then started to work on Specifications and Types to define the data flow between them. Just not sure if I was going about this in an orderly way.

So perhaps I should ask my question in a more general way that applies to UML/SysML the same:

What does a typical development workflow look like?

i.e. develop all the use cases first, work on attributes, classes. Create a sensor, define all the sequences, then state transitions then use cases etc.

I'm reading as much as I can but all the books are about what diagrams do and representations, not where to begin and how to proceed.

Best,

M.

[qwerty]

I guess your question is bit too broad to be answered here. There is no short formula for what you're asking except: read, google, learn. It takes a lot of time to find your goal.

I started learning the ICONIX way. I also tried to summarize such a general approach in my BA-book. You can read online if you like.

q.

[Gary]

Medic
Use SysML either 1.2 or 1.3. Most of the books out ther use 1.2. Good reads are
1) SysML Distilled by Lenny Delligatti, for the usage of all the language.
2)Systems Engineering with SysML/UML for an idea of a process to follow.
Basically you can follow a systems engineering process as a workflow guide thus:
Analyse requirements (verb(functions, use cases), noun(blocks, data) analysis)
Create a context diagram(not SysML but useful) put your system as a black box block in the middle and create actors for all the interfacing systems and people around the outside. Then for each actor ask how do they interface with my system, what functionality do they require, what data is passed?
Then create usecases or information items/flowspecs/interfaces to answer these questions.
Rationalise the usecase and data flows items created to a core set of elements that provide for all the interactions.
Link the usecases to any functional requirements using <<refine>> connectors.
Create testcases for the usecases NOW not later but NOW. This is important as it will highlight some problems with some of the usecases as it is easy to create a functional description that is not actually testable. Also helps in identifying alternate scenarios.
Link testcases to requirements that they <<verify>>
Fully document the usecases with sequence diagrams and state transition diagrams.
Create Activity diagrams for any important operations that need documenting.
Now look inside the black box and identify any internal blocks that stand out at the next level of abstraction. Create a context diagram for each of these next level blocks with an actor representing any external systems. Repeat above steps.
Repeat whole process at subsequent levels of abstraction as necessary. 2 or 3 usually does it unless you are doing systems of systems design.
The last level of abstraction becomes the software/hardware teams intial architecture analysis. Hand over to them.

Hope this helps

Gary

[Medic]

Thanks for the detailed reply.

New to EA, not to the concepts and writing embedded code. Most of my headaches have been figuring out the relationships between all the different package types and diagram elements.

I've defined all my states for an object and am now stuck figuring out how sequence and timing diagrams interact with the state diagrams. In my head the state machine should be exercised as a sequence which uses those objects runs through, but I've not got there yet...

thanks for the recommendations. I'll get those for my collection.

So far I read:

UML In Practice
Model Driven Development with Executable UML
Modeling and Analysis of Real-Time and Embedded Systems with UML and MARTE
Modeling Embedded Systems with SysML
Practical UML statecharts in C
Sams teach yourself UML in 24hrs
SysML distilled
UML Demystified
Use case driven Object modeling with UML - Theory and Practice

[Gary]

Medic

Sorry If i went a bit too detailed I read "new to UML" in your first post and went into full tutorial mode  

I found the same issues when I first started about figuring out the relationships between all the different package types and diagram elements. The books are good at the language and concepts and rubbish at how to organise a model to enable someone to find all the related information.

I put the sequence  and state diagrams under the usecase that I am elaborating so they are easy to find.

To link sequence and state diagrams I make the trigger that causes the state change to be a call type and use the object operation as the specification. That then links the operation to the state change. alternatively if the trigger is a signal that then causes a message then use then put the operation in the guard and check 'Effect is a behaviour'. Alternatively putting a state on the sequence diagram is valid.

I always find people new to the modeling want to put what the object does into a state diagram when its purpose is to show the states it goes through in response to stimulus(messages/signals etc.) Apologies if I am telling you stuff you already know but it is also useful for others who come along and read these.

Gary