May i know how to draw a Block Diagram for a system/ software development? I searched online and i couldn't find any guidelines or good example.
What should be on the top in Block Diagram?
Should i arrange the Block Diagram based on my Class Diagram (Inheritance, interface, abstract etc)?
Why use Block Diagram?
What does Block Diagram actually show? The process? The component? The overall architecture?
Can anyone please provide me any links regarding Block Diagram if there is any?
A block diagram is helpful mainly in the preliminary stages of software development.
A block diagram is similar to a UML package diagram in that it only shows very high level components of the design and how they interact.
What should be on the top? There isn't really a "top" in a block diagram. You may be confusing this with a layered architecture diagram. In a layered architecture diagram, top-level layers are generally the closest to the user.
Should I arrange the block diagram in terms of Inheritance? Not really, the block diagram is supposed to show only the high level interactions of the system. A UML class diagram is where you show the inheritance and interface behaviour.
Why use a block diagram? Primarily because it is easy to partition the system into components for component-based software engineering and because it makes it easy to discuss with clients/managers.
The block diagram generally shows the overall architecture.
This is an example of a layered architecture diagram:
(from http://www.acaltechnology.com/index.php?page=news&id=1577)
This is an example of a block diagram:
(from https://web.archive.org/web/20121106145142/http://www.simventions.com/whitepapers/uml/3000_borcon_uml.html)
The best way to draw a block diagram is using parts and connectors of the Composite Structure UML diagrams.
Related
According to UML context diagram context diagram doesn't exists.
So my question is which one of UML diagrams is good to show something like this and how to paint this?
I've just found the following definition: http://en.wikipedia.org/wiki/System_context_diagram
That's probably what you need. :)
A context diagram defines a boundary between the system, or part of a system, and its
environment, showing the entities that interact with it.
There is no single diagram in UML that would map to this definition, but I have some good news - there are several diagrams (out of total of 14) that can show the frontier between the system and its surrounding world from different perspectives. This is much more flexible than only a context diagram.
First of all, I would mention a special UML element - a boundary. It can be used in any diagram type to show some kind of delimitation. You might want to optionally use it to visually delimit between the system and its environment, especially in situations when this is not explicit.
The following diagrams can show the boundary between the system and its environment:
Use case diagram (your example) support the context explicitly on the functional level. Use cases are elements of the system under development, while the actors are extern entities (systems or human users). Before mentioned boundary is often used to visually delimit between the system and its environment.
Component diagram is used to model some kind of software modules (applications, DBs, external systems, libraries, etc). You can use it to show both internal and external components and the way they interact. A boundary can be used to clearly draw the separation line.
Activity diagram can show your system/business/usage processes. Some activities can be performed internally, others externally. Here you don't need the boundary, but the so called swimlanes to depict who does what.
Sequence/collaboration diagrams are another option. They show the communication sequences between several objects. If you split those objects in internal and external ones and wrap them up with the boundaries, there is another context diagram. :)
UML is flexible, there are probably further options, but I think this is enough to get the idea.
Names of your association are services. UseCase in center of diagram is context of services definition. See usecase diagram:
It could be done with a use case
http://en.wikipedia.org/wiki/Use_case
EDIT:
Reconsidering it, use case diagram should be the next step once the operations are defined so first you shouls make a system sequence diagram.
http://en.wikipedia.org/wiki/System_sequence_diagram
If you're happy with going into the not complete superset of UML that is SysML, you can have proper Context diagrams there.
However, context diagrams in SysML are simply Block Diagrams showing system context… and Block Diagrams happen to be the same as UML2 Class diagram, where the classes are of stereotype «SysML::Block».
So you can define your context diagram in terms of aggregation of blocks to your system, with the relevant stereotypes, basing it on UML2 Class diagrams.
I tend to use collaboration diagrams for this. So for each major scenario of each use case, draw a collaboration diagram showing the actors, with the application as a single entity in the middle, and messages travelling around that show how the application interacts with the actors in order to fulfil the scenario.
(I don't put too much detail in the messages -- I only want to show that there is a delegation of responsibility and some kind of interaction, but I don't care about details of actual messages, views, data etc.)
I find the context diagram does have a particular appeal. It sits well with business users, showing them the scope & parties of a system in a very easy way. So, I tend to create a context diagram, even in contexts where UML is prevalent.
Which UML diagram is the best for showing dependency between our IT system and other external IT systems?
For example I would like to show on diagram:
system A gets data from system B
system B can call some functionality from system A
I'm wondering between component diagram and sequence diagram.
What do you think?
your question is not very specific as all UML diagrams display some kind of dependency or pathway how to get data or make a call, so I'm not sure if I got substance of your question right
1. there is no such thing as one best UML diagram to show it all
There is usually one system that you are modeling (+ some black boxes in its surrounding environment) and one UML model. At best the tool you use should support Model Driven Architecture (MDA) and perhaps even Executable UML so that the result of your modeling can be more then set of "pictures". It can become skeleton of source code forming the backbone of the application or it can be even model-click-and-run product.
In order to provide full or sufficient description of the system you'll usually need more UML diagrams each representing different point of view with focus on different aspects with different level of detail (yet all of them being parts of one model).
(This ↑ was the hard part for me to understand)
2. before deciding which diagrams to use make some paper & pencil prototypes
It is quite importtant to make sure which diagram fits your needs before you start drawing it in a good looking sharable form using a tool. Even drawing in Enterprise Architect takes some time to get used to and to get it right.
Very good guide how to do a paper & pencil diagrams and which of them is used for what and how to spend only as much time as is needed:
Agile Modeling - Start Here
...
Agile Modeling - UML 2 Component Diagrams: An Agile Introduction
Agile Modeling - UML 2 Sequence Diagramming Guidelines
...
3. sequence diagrams are expressive simple and useful for programmers
There are even tools that can turn sequence diagrams into code or tools that can turn source code into a sequence diagram.
overview UML sequence diagrams overview of graphical notation
overview IBM Rational Edge - UML basics: The sequence diagram
tutorial Enterprise Architect - 14 minute video - Create Sequence Diagram
4. activity diagrams are expressive and useful for programmers
overview Debenedetti Emanuele, Activity diagrams in UML 2.0
background by Conrad Bock (one of UML authors), UML 2 Activity and Action Models, The Journal of Object Technology
UML 2 Activity and Action Models
UML 2 Activity and Action Models, Part 2: Actions
UML 2 Activity and Action Models, Part 3: Control Nodes
UML 2 Activity and Action Models, Part 4: Object Nodes
UML 2 Activity and Action Models, Part 5: Partitions
UML 2 Activity and Action Models, Part 6: Structured Activities
tool manuals
PaceStar UML Diagrammer, UML Diagramming Guide - http://www.pacestar.com/uml/udg60.pdf
Sparx Enterprise Architect, Using UML Part Two – Behavioral Modeling Diagram - http://www.sparxsystems.com.au/downloads/whitepapers/UML_Tutorial_Part_2_Introduction.pdf
Microsoft Visual Studio, UML Activity Diagrams - http://msdn.microsoft.com/en-us/library/vstudio/dd409360.aspx
5. high level overview diagrams useful for programmers and others (not UML)
poster Business Process Model and Notation
Wikipedia - Business Process Model and Notation
clear expressive language easy to comprehend ARIS Event-Driven Process Chain (EPC) (my favorite since the first time I met it back in 1999)
6. = 1 + 2 + you
make some paper & pencil sketches and decide yourself which diagrams best suit your needs
Further to your thoughts and what Aleks has said, people usually use a combination of both to articulate the inter-system relationships
EA allows you to reuse components in component diagram & Sequence diagram, which allows you to update model from one diagram and have the changes reflected in the other.
Below snapshots show how two components in the model are used in a component diagram (for structural relationships) and sequence diagram(for behavioral flow)
Components definitelly, and dependencies. Dependency does not go in direction of the data-flow, but from the component that "knows" other component (invokes something from it, creates an object, etc).
The following diagram shows the idea.
It is common (and highly recommendable) practice, to use interfaces between the components and channel dependencies through interface. This permits clearer specification and better design (if possible of course).
Sequence diagram can further be used to specify concrete usage scenario and is also recommendable. So, components for structural, static dependencies and sequence for dynamic behavior.
I am new to UML. I have studied more tutorials.I learned two broad categories like,
UML Diagrams:
1. Structural Diagrams
Class diagram
Object diagram
Component diagram
Deployment diagram
2. Behavioral Diagrams
Use case diagram
Sequence diagram
Collaboration diagram
Statechart diagram
Activity diagram
But I dont know which one is high level design and low design. Anyone list out the UML diagram types based on priorities. (high-level diagrams to low level)
There is not really a well-defined order of higher-level versus lower-level diagram languages in UML. The same diagram language (e.g. class diagrams) can be used at different levels of abstraction. For instance, a conceptual information model, but also a Java data model, can be expressed as a class diagram.
Generally, a use case diagram is higher-level, since it describes requirements, while a deployment diagram is lower-level, since it describes system deployment structures.
But all other diagrams languages can be used at different levels of abstraction.
UML diagrams - from the most common to most detailed level.
Please, notice, that nowadays (the start of 2014) there are no special instrument for UI modelling. So, I'll explain how to do this part of work, too, with the tools we have. But they will be used in a less or more nonstandard way.
Human level. Use case diagrams and state machines. How people will work with the system.
Use cases are about what the system does, who works with it and maybe, grouping of those subjects. Subsystems can be defined here. Try not to show much structure or behaviour. Not to use any IT slang!
State machines show what states the system, subsystems and actors can have and what actions/events can happen in these states and to which other states can it lead. Not to use any IT slang!
Do not forget, that administrators, programmers and testers are users of the system, too. So, plan not only how the system helps to the work of the common user and his senior, but also to the installation/administration/testing/support processes. Don't forget to continue this work on all deeper diagraming levels. These use cases/state machines needn't be so human-oriented.
You can draw activities, sequence, timing diagrams for some dialogues between Actors and subsystems, if they are the part of the requirements. Or make them the part of requirements if they are important. Not to use any IT slang!
Draw the sketches for the UI and talk over them with client. The work on UI art design should be connected to UI planning and realization
Start to work on User Guide - create plan and structure. (I use class diagrams for that).
Deployment and component diagrams. Here you are starting to imagine the inner construction of your system
Components - What compact parts it has. It needn't have much in common with the subsystems, as user see them. Only some components are visible to the user. You could decide on the use of some interfaces between them. Think on the license problems of the third-party components.
Deployment - how the components could be distributed among PCs. The same question about interfaces, but more from the physical side.
A special deployment diagram for license politics of your product could be drawn, too. You can use other diagrams for it, as well. It is at your choice.
You could already plan your user interface by these diagrams, too. In MVC (model-viewer-controller) construction only the components of the controller level are mutually connected and obviously need this level modelling. But the viewer layer (UI) components are connected in a conceptual way, they should be, for the sake of user. So, it should be planned too, by the same diagrams.
On this level you also plan the architecture of the development environment. It consists of components, too.
Draw Interaction Overview and Communication diagrams to see the cooperation of components as a whole or in complex groups.
Package, activities, sequence, timing diagrams
Package diagrams are for planning the hierarchy of your code and mutual visibility of its parts. Don't forget the place for testing packages, too. Notice, that the structures of packages and components hierarchies are different, but they have to work together. It is very important part, frequently overlooked.
Use behavioral diagrams for better understanding how different processes could run.
System analysis - the class diagrams level.
Some important classes could appear on the previous level diagrams - as definitions of intercomponent interfaces or subjects of processes. But now you should do all of them. Minimally a diagram for a component. You should do these class diagrams, using ready package diagrams.
Plan the content of UI, defining elements and functonalities and connections between them WITHOUT choosing the concrete components. Use diagrams that you like. Class ones are usable, but in not standard reading.
Deeper insight
If you have instances with specific behavior, use Object diagrams for their planning.
If you have some very complex classes or their tight groups, use Composite Structure Diagrams.
UI: Plan the content of screen elements WITH choice of the UI components (frames, buttons and so on) and connecting functionalities to them. On this level you can again use class/object and sequence/timing diagrams.
Code. Really, the coding, at least on the prototype level starts already on the stage of component planning. You have to control if and how different technologies will cooperate. But the real coding should be done only after you are sure you understand what are you doing. And to create all or some correct diagrams is the best way to be sure in it.
Notice the rule of thumb - structure diagrams set the sequence of levels. Behavioral diagrams support them on all levels. You can use state machine on the lowest level and timing diagram for to discuss with a client. But try not to mix the levels with the structural diagrams!
Also, do not try to mix diagrams, especially behavioral with structural ones. You should clearly set the rules, by which you can say, what part of information can be on the diagram and what not. And break these rules really only in the most exceptional cases.
As gwag noted, there is no separation of UML diagrams into high and low levels. The different diagrams are used for describing different aspects, not different levels, of a (software) system.
But if you look at UML in a broader context, the Unified Modelling Language is just one of a whole family of modelling languages standardized by OMG. These different languages do have more specific scopes.
SysML (Systems Modelling Language) shares many features with UML and looks very similar, but is specifically intended for the higher levels of systems analysis / design. It also includes a visual representation of requirements, which are conspicuously absent from UML.
Another related language is BPMN (Business Process Model and Notation), which is used for business processes. So you could for instance use BPMN for business analysis, SysML for system design and UML for software design.
UML does not specify level of details you define in diagram. Every diagram can be used for description on business level, implementation or design level as well.
It is up to modeler, what type of diagram uses to descrbe modeled system. Information in diagrams must correspond with each other and all diagrams must give complet view on system.
For example, you can declare services of Bank company using UseCase on business level or use UseCase to declare services implemented by concret physical component of program writen in Java.
I am not a big fan of UML. I believe UML is great in some rare instances, however I do not want to use a UML diagram to show a high level flow of calls through my application. Problem is - most of the tools (visio, lucidchart, websequencediagrams) force the user to either draw a very detailed UML diagram, or a sequence diagram. There is nothing that would be like a high-level version of a UML diagram. Or is there?
There is no such thing as a "higher level" UML diagram. UML has 12 (or was it 12? I can't remember) and you must choose from one of them, the best that fits your needs.
For a high level flow of calls I like activity diagrams, even though the objects that own the functions are harder to see. Sequence diagrams are a waste of time and space IMHO .
As we known . The sequence diagram in UML is a kind of interaction diagram that shows how processes operate with one another and in what order Between the Class or Object.
Now I am trying to find a diagram in UML or some tools to describe interaction and operation order of distributed system. Is there any diagram or tools which model the interaction between Distributed system like sequence diagram ?Thanks.
Activity Diagrams are the UML diagram to use in this situation.
Wikipedia Activity Diagram
Agile Activity Diagrams
Sequence and communication diagrams aim to show how "things" interact. These "things" could be objects, components or complete systems
You can also use sequence diagrams to describe interaction between components in a distributed system, each lifeline designating one of the system components.