Does JDT provide any APIs to generate control flow graph?
I used soot to generate control flow graph,but can I use JDT to generate control flow graph?
JDT sure provides all necessary information, but you may have to invest some code of your own, to get exactly that data structure you are seeking.
Much depends on the level of detail you are interested in: A call graph between methods? Detailed flow of basic blocks within a method? A combination of both?
If your interest is related in spirit to refactoring, you may get some inspiration from the internal code in JDT/UI that is used for flow analysis on behalf of refactorings. Have a look at the following sections of source code:
data structures below org.eclipse.jdt.ui/core refactoring/org/eclipse/jdt/internal/corext/refactoring/code/flow
usage of the above in classes like
org/eclipse/jdt/internal/corext/refactoring/code/CallInliner.java
org/eclipse/jdt/internal/corext/refactoring/code/ExtractMethodAnalyzer.java
Related
According to "Head First Object-Oriented Analysis and Design", Complex projects involves first finding a feature list -> drawing use case diagrams -> breaking into smaller modules before implementing object oriented design (requirements gathering -> use cases -> OO -> design patterns etc.)
I want to understand, what is the criteria for the size of project when feature lists and use case diagrams should be implemented before finding requirements and writing use cases?
I am particularly interested in how can this knowledge be applied to my real wold problems
Example, I am working on a UI that send instrument commands to the server and displays the response back from the server. I know from customer feedback that the UI should have the following things:
It should be able to let the user select an instrument from available list and send any custom command and display the result
It should be able to let the user select an instrument and a command from available list and display the result (create commands using drag and drops from given lists)
It should be able to have capability of creating macros
Is this UI project small enough to not have steps for gathering features and drawing use case diagrams? Do we go straight to categorizing the asks as requirements and start gathering requirements and writing use cases?
How would one go about breaking down project of this nature to deduce it to its appropriate class diagrams?
I have tried considering the above mentioned asks as features and then tried creating requirements, mainly on the different states that one could have during the life cycle of the UI application but I am still not sure and unable to comprehend the teachings of the books on this project.
I haven't read the book, so I'm not sure what the author(s) of the book really wanted to emphasize here. But I assume that you misinterpreted it.
Without knowing the requirements there is no feature list. If you don't know what is needed then you can't say anything about the system's capabilities.
Gathering requirements is an iterative process. First you gather the high-level requirements in order to be able to start building a mental model about the system. This can help you to start think about the supported features. By sharing your mental model and the exposed feature set of the system with the stakeholder, it initiates the next iteration.
Here you can start talking about actors, user journeys, use cases, etc. These are mainly focusing on the happy paths. As you have more and more iterations you will reach a point where you can start talking about edge and corner cases: What suboptimal cases can we foreseen? What can we do (prevention, detection, mitigation)? How does it affect the system/actors/journeys?...
The better you understand the needs and circumstances, the better the design and implementation of the system could be.
UPDATE #1
Will we always have high-level and low-level (edge cases and detailed use cases) requirements i.e. we will first need to make use case diagrams and then write individual detailed use cases?
There are a lot of factors which can influence this. Just to name a few:
Is it a system, submodule, or component design?
Is it a green or a brownfield project?
Is the stakeholder experienced enough to know which information matters and which doesn't from the IT project perspecitive?
Does the architect / system designer have previous experience with the same domain?
Does wireframe or mockup exist at project kick-off?
Should the project satisfy special security, legal or governmental regulations?
etc...
In short, yes there can be circumstances where you don't need several iterations, but based on my experiences that's quite rare.
I'm using BPMN2.0 meta-model to represent process models. I cannot find any attributes to keep execution historic. I'm wondering if actually BPMN 2.0 does not support that, or if something escapes me?
In other words, my question is: is it possible to represent execution historic with BPMN 2.0 meta-model? if yes, how?
Thank you for your help.
BPMN supports the Elements Auditing and Monitoring. They are meant to be hooks for auditing and monitoring related properties. For the definition of such properties the extensibility mechanism is to be used. Actual definitions are out of the scope of the specification. So, the answer is, that BPMN supports this, but leaves the details to the user or the tool vendors.
I'm building an API and I have modeled the entities I need inside it. By example
User
Name
Email
City
Company
Name
Website
I'm using Blueprint to specify the API itself and I need to create endpoints for CRUD operations in pretty much every entity. The task seems very redundant to me - besides some tuning that is needed in some specific entities, most of the basic skeleton looks like the same.
I wonder if there is any tool that allows me to write down my entities, its fields and types and generates this basic skeleton.
I was about to start creating one and then I stopped to look around if there already is one but I did not find anything yet...
API Blueprint contains a tool to write, use, reuse, compose, inherit your data structures, and it's MSON.
Basically it's a way to describe your data structures within an API Blueprint. We do also provide an html renderer for that, and it's the Attributes Kit. Try also to have a look to its Playground.
You can find an useful tutorial on official website, as well more information.
Hopefully it should be enough to get started.
Cheers,
V.
This question is related to diagraming a software process. As an electrical engineer, much of the software I do is for embedded micro-controllers. In school, we learned to illustrate our algorithm using a flowchart. However, nowadays, many of my embedded projects are heavily interrupt-driven where the main process runs some basic algorithm a variety of interrupt sources provide its stimulus. So, my question is, what are some diagramming techniques that I can use to illustrate my process such that future developers can understand what I am doing easily and get involved in development?
Here are some key features that I am looking for:
Shows data structures and how data is passed between processes & interrupts
Shows conditions that cause each interrupt
Shows how data is gathered and passed through a downlink
Shows how command messages are received, parsed, and executed
Ideally is well suited for hierarchical breakdown into smaller processes with greater levels of detail
I've always seen interrupt timing drawn as follows:
Or inline line so:
But I prefer the former as it gives more room for annotation.
In response to your comment, perhaps a UML state machine diagram (with some adaptation) may be closer suited to your purpose:
There are many of interesting approaches you can find in diagram drawing. I will post a few here. You will find a lot of Operation System and Architecture scpecific names in there such as register , event, function names and etc. It is more for representation so far, right? So he we are.
Use UML class diagrams for showing data structures. Use sequence diagrams to show interactions between classes and interrupt service routines (showing function calls only). Use activity diagrams to show how interrupts interact with processes (signals are good for this). An activity diagram can also be used to show the process of receiving data, parsing it, and dispatching it. This can also be represented in a static view by a package diagram where the command handler is in one package and the command parser is in another, connected by a dependency line. Use cases are good for a high level view of functionality.
The main point is that UML supports many different views (static, dynamic, logical, deployment) into your system. Don't try to express everything at once.
The diagram below shows an example of an interrupt to a process.
I'm working on Software Test Plan Document and I'm confused about diagram that I should use when making white-box testing. What's the difference between activity diagram and control flow graph? And which one should I use?
An activity diagram represents the behaviour of your system. The actions which the user can make or the system can make are linked with a, control or b, data flow.
The control flow diagram contains the progam logic with weights and guard conditions.
In a software Test Plan I would suggest first to use an activity diagramm to get the general overview. To express explicit logic, you can have an additional control flow diagram.
This depends on you system under test, and you have to chose the right diagram depending what kind of SUT you have. Normally you need several diagrams to give light on different aspects.