Functional design of an embedded system

[deefer]

Hi

I'm developing an embedded system (HW/FW) and I'd like to develop a functional design of the system.

I'm using SysML.

I was reading about the MCSE methodology described in the CoFluent site and they use sysml blocks to describe functionalities.

My question is: which is the best way to describe the functional design of the system? to use blocks or activity diagrams?

IMHO, bloks can better be depicted in a situation where I have to show the relationship between the I/Os of the system and the internal functionalities; on the other hand, activities (expecially in SysML) have already some notations to describe events, time events and execution order of the functionalties.

Also: how to map activites onto "real" FW classes? Is it ok to use the "allocate" relationship?

I know it is a big topic but some suggestions would be very welcome...

Thanx Davide

[beginner]

Too big indeed. A few words:

• You can use <<allocate>> between blocks and (business) UCs.
• (Technical) UCs can be placed inside blocks.
• Partitions can be classified by blocks to identify responsibilities.
• Find the right structure (here it is Req-Actors/UC-Architecture (Blocks)-Devices-Logical Design).
• Don't use too much of the possibilities SysML offers.
• Think about what you need to communicate to whom and reduce to the min.

It took me almost a year to get the right picture here.

b.

[deefer]

Thanx beginner

•You can use <<allocate>> between blocks and (business) UCs.
I assume you mean to assign the system functionalities to its subsystems

•(Technical) UCs can be placed inside blocks.
OK

•Partitions can be classified by blocks to identify responsibilities.
OK

•Find the right structure (here it is Req-Actors/UC-Architecture (Blocks)-Devices-Logical Design).

I've read some literature and it seems everybody has a different approach to this...  

•Don't use too much of the possibilities SysML offers.
OK

•Think about what you need to communicate to whom and reduce to the min.

In fact I have to communicate with people used to see functional block diagrams... if I show them activity diagrams (with partitions...) they get quite confused... on the other hand I'd like to follow a "standard" approach... and I'd like to avoid redundances in the model by doing two times the work...    

Let's say the approach proposed by MCSE is quite appealing and intuitive for me.. unfortunately I've already started many months ago to depict the uc-activities of the system/subsystems...

Yes, I'm confused
D

[beginner]

I assume you mean to assign the system functionalities to its subsystems

Yes. That's the intention. As can been guessed below you have to respect two levels: business and technicians. I model UCs first from business perspective while <<realize>>'ing requirements. These are placed in a "Use Case View" package. Second I try to find architectural blocks which then hold technical use cases (placed directly inside the blocks). Devices are also placed in an own package whenever they pop up in the design phase. There are different ways to group these (none is the best). These devices are related via <<use>> relations to the business UCs (like actors). In the beginning I had lots of stickmen but then I found out it was better to directly link concrete devices (which have a nice shapescript decoration here). That gives a good picture to the techies and also the customer gains understanding of the delivered system.

I've read some literature and it seems everybody has a different approach to this...  

Yes, of course. Mine has developed over a year for my current customer. Others might think different. YMMV

In fact I have to communicate with people used to see functional block diagrams... if I show them activity diagrams (with partitions...) they get quite confused... on the other hand I'd like to follow a "standard" approach... and I'd like to avoid redundances in the model by doing two times the work...    

Of course. Redundant work is bad. However, I had good success using activity/partition. When you use action pins over partition borders, these are the first step to interfaces. It takes some practice to get it right but once you got the idea it's almost self-explanatory. One important thing to mention: when you classify partitions with according devices you can Ctrl-U the devices later to find out where they are active.

Let's say the approach proposed by MCSE is quite appealing and intuitive for me.. unfortunately I've already started many months ago to depict the uc-activities of the system/subsystems...

Don't be afraid of starting at the beginning once again. You likely have to take several jumps to cross the fissure. Just communicate the necessity to do so. Nothing is worse than "we started this way and despite the fact we know it's wrong we will continue".

Good luck.

b.