How to model the components of a non Information System?

Question

I am working on a kernel-related project (specifically related to the TCP/IP stack of the kernel).

I need to build some models to describe the functionality and components of my system. Initially I thought about using a Class Diagram, as it can describe the general architecture of my system. But it doesn't make sense since my code is VERY structured (written in standard C).

I also thought about DFDs: they'd describe the processes of my system, and how the data is flowing. But they contain something which doesn't really fit in: data-storages. I have no databases here (at all).

For the functionality, other team members suggested using Activity and Sequence diagrams, which is kinda okay with me, but what about the system components?

So basically my question is: If I want to describe the components of my system, what do you suggest as a meaningful diagram ?

Again, the project is a research low-level systems-oriented project with almost no user-interface at all.

Answer 1

Then, why don't you use UML to build a Component diagram or even a Package diagram? If I understood correctly, you want a bird's eye view of your whole architecture and that's why you don't need a class diagram, right?

I guess you could even look at SysML which can provide a more systems-oriented approach.

Answer 2

All the documents you described will work to describe your system from the perspectives they capture.

A class diagram is to show the structure of your project without needing to see the code, the fact your code is very structured is irrelevant.

A DFD does not need to have a data storage listed, not all systems store data, but its still important to map how data flows through the system even if the data leaves the system as an end condition.

Answer 3

The UML is probably one of the few languages that only supports just one paradigm: an OO paradigm; this is why you simply can't express something like interfaces, the UML can't compute your request.

In my opinion the roots of a good documentation about a project are:

• a list of all the typedefs used
• a list of types if the language is OO
• a list of all the interfaces
• a list of all the templates if required ( if supported by the language )
• if the design is OO the UML can be considered ok just for expressing the business of your classes.

just with interfaces and types/typedefs you can say a lot about your project.

A diagram also involves the concepts of "relation" and/or "flow", the problem is that you do not seems to be clear what paradigm are you using in your application.

C is intended to support a procedural and a structured programming paradigm, a diagram does not make too much sense in my opinion because you will end up with a series of boxes and arrows one after one, you will basically rewrite the code in a flow chart without describing any logic and, the most important part, without having the chance of abstracting that much.

Answer 4

As @Astyanax said, UML Component and Package diagrams are generally-useful even in non-OO systems. State-Transition Diagrams are another form that are commonly seen at the system level. I actually like the idea of DFDs, too, even if you don't have datastores: I've always found them to be pretty accessible for both technical and non-technical users (you don't have to know all the semantics of "filled diamonds" vs "unfilled diamonds" etc.)

Answer 5

I can only share my personal experience.

I have designed many systems in different environments (the most serious is the framework of some government agricultural data management systems), both backend and frontend things. I have tried to use UML many times (Rose, Enterprise Architect and ArgoUML), but failed with the same reason as yours. The UML notation is too limiting, and instead of allowing me to express and refine my ideas in an easy-to-share way, it tried to force my thinking into its terms, and I spent all my time in searching for the best diagram type. And anyway, not only I would have to spend a lot of time LEARNING that stuff, the results would be readable only for those who learned the same...

So, my result is: trash UML, and find a good charting software! My focus points in selection: first of all: draw smart, labeled lines that follow the shapes, and it should also allow easy reorganization, coloring, have a library of nice shapes. Your audience will love that too. Right now I have found gliffy.com, perhaps a bit too simple, but "good enough" tool for my current needs, and even my son can use it :-) But there are many others of this kind.

Spend your precious time on freely drawing your ideas, and create a simple, consistent notation (shape, color, line, text coding) that you can explain in just a minute - and express that this is NOT UML. For me, it works much better than the holy UML in reality, at least with my colleagues and audience.

And hey, I can write better code than what a UML tool generates, and would NEVER use the tool generated and updated code in a real system (only if I write that tool, which is in my long term scope :-) ).