I am writing my Bsc. thesis about a transaction which involves several software systems. Its basically about the communication and information exchange of a ERP system and a webservice which I am implementing. There is a module on the ERP side and the web service on the other. The transaction is communication with XML files.
I want to model this process or transaction and don't know the right modelling language for that purpose. Is the UML component model the right one?
I also want to annote side information like the programming language I am using at a certain step in the process or which XML standard is beeing used. It would also be nice to annotate the asynchronous HTTP sending and receiving in the process.
Thanks for your help!
Marco
If your primary goal is to document the interactions among web service and ERP module then the most appropriate UML diagram is likely either a sequence diagram or activity diagram.
Both will help to show the protocol (sequence of interactions). Both can be annotated with anything you like using notes or constraints.
If you're trying to capture more specifics on the representation of messages UML may not be appropriate. Its strength is showing the structure of the interaction, less so structure of the messages themselves. If you want to show that detail it may be more appropriate to look at some of the web service standards, e.g. WS-choreography.
hth.
Related
I am just learning BPMN 2.0 modeling language.
I have to design a call center process where an operator asks several questions to a customer.
I am wondering if I need to model a message flow between customer and operator for every question (as the exchange information) or if a message flow is only needed if real documents are exchanged (e.g. an invoice is sent).
Thanks!
Let's look at the definitions in the BPMN 2.0.1 specifications (highlighting from me):
Message: An Object that depicts the contents of a communication between two Participants. A message is transmitted through a Message Flow and has an identity that can be used for alternative branching of a Process through the Event-Based Exclusive Gateway.
Message flow: A Connecting Object that shows the flow of messages between two Participants. A Message Flow is represented by a dashed lined.
So the message is not necessarily a business document that is exchanged, but any kind of communication, including spoken exchange.
The granularity of the messages depends on what you want to show in the model:
If the question/answer is just a detail in a larger process, you may want to show one summary interaction corresponding to the questions and another in reverse direction for the answers, and consider that all the questions are asked at once and all the answers provided at once, even if this does not fully correspond to reality.
If you're interested exactly in the details of the question/answer because for example different participants are involved at different stages of the Q&A, you may well single out each question and each answer separately according to the real flow. But be careful, since too detailed flows might be difficult to maintain, so some degree of abstraction is recommended.
If your interest is in very detailed dialogue scripts between a customer and the same operator, BPMN might not be the best tool: more specialised conversation flows, job stories or intent based scripts could be more appropriate (see more about the topic in this article on chatbot requirements)
Intro
The company I work in (it is an intern-like position though, until I am done with university) recently implemented an automated warehouse solution, where goods are transported by means of autonomous shuttles. The basic functions of the shuttles are controlled by onboard electronics (microcontroller), routing through the warehouse racking is done by software solution which in turn communicates with our ERP solution. Effectively the ERP solution handles the whole warehousing.
Task
There are well documented processes for every of the four layers (operator who loads the the shuttles, shuttle itself, routing, ERP) individually. But since we kind of puzzled all four of them together to one solution (which was kind of new to all of the participating companies), there are only vague, on-the-flyish process descriptions involving all four layers available.
Now I have been tasked to come up with a solution to illustrate the processes at work.
Example
ERP signals goods in demand at assembly station A1
Warehouse operator looks at screen and starts loading boxes to be picked up by
shuttle
Warehouse operator puts in details into ERP, such as count/weight, box number,
...
Warehouse operator clears boxes for pick-up (by confirming inputs in ERP)
ERP generates transport order
ERP sends transport order to routing software
Routing software sends telegram to shuttle control
Shuttle control turns wheels and asks for directions to pick up boxes
...
Question
As mentioned, I have to graphically represent the kind of processes similar to the one shown in the (easy and not complete) example above. I need to incorporate the operator's actions as well as basic communication between shuttle, routing software and ERP.
Since I attended a course on BPMN at university it came to mind immediately. But now, after immersing myself into information about BPMN for several hours I still can't conclusively tell if BPMN helps my efforts or just further complicates the whole thing.
Is BPMN the right tool for my purpose?
Disclaimer
I am not a Business Analyst. I have looked at alternatives to BPMN (simple flowcharts, activity diagrams, ...) but they don't seem to fit.
Just putting together the existing processes for every respective layer yields no result, owing to the different and sometimes too detailed process descriptions.
Edit
The ERP is SAP ERP 6.0 EHP7 with integrated WMS component.
TL;DR: use the notation you would be implement process in, i.e. choose BPMS, not BPMN.
The notation itself means nothing unless it has proper tool for modelling and further process implementation aka BPMS. You can find dozens of comparisons (e.g. BPMN vs EPC or BPMN vs BPEL), however they won't help you unless you have clear understanding where and how you will be implement you modeled process.
Generally speaking, EPC is used for more high-level view of the process, whereas BPMN is utilized for more fine-grained view, where all technical details of communications between peers can be described. However, it depends.
I also recommend you to review this table
and answer the question to yourself whether your process changes (in)frequently or not, and whether you need separate BPM tool.
How I see it from your description: you have four participants (four layers), which are four lanes in BPMN terms, and they are collaborating/communicating with each other during the process. Generally speaking, this fits to BPMN application area, but personally I feel that you should stick your ERP tooling. I don't know which ERP you use, but every serious ERP solution includes tool for process customization. For example, SAP has Workflow,
which can widely enhance and extend existing processes within SAP. Probably, your ERP have it too.
Again, it's not clear which warehouse management system you use and if it is integrated to your ERP. It seems to be not, and it seems to be some old legacy system, because of which you start re-modelling the stuff. In this particular case it might me wiser to acquire special advanced warehouse management package (take a look at SAP's EWM features as an example) which can cover most of your requirements.
I am studying Object Oriented Design and am using usecases with actors and scenario''s to plan out the application i am trying to build. No specific language yet, just the theory at the moment.
I have come to the point where i have identified and written out the use cases for the users, administrator, owner, etc and also the external systems like the feed generator.
but i have come to realise that my application actually consists of multiple smaller apps. like a data gathering application and a analysis application.
Can/should i use the data gathering and analysis app as an actor in the overall application too?
I can write specific use cases for them, with scenarios etc.
Typically, no.
Actor is an entity that sits outside of the system and produces some action. It gets to the system boundaries, but then all interactions between system components are modeled not as usecases, but as i.e. dynamic diagrams or sequence diagrams.
For the record, I think this approach is flawed and doesn't really help you in building applications. I personally prefer thinking about components and their interactions directly, without forcing the idea of architecture to fit a particular modeling scheme.
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 developing a 3 tier architecture for an MVC4 webapp + EntityFramwork5.
I want to keep separete the layer, so only DAL knows that I'm using EF, for example.
Actually I have a lot of classes to manage that:
DAL
Entity POCO
Entity DataContext : DbContext
Entity Repository
BL
Entity ViewModel
Entity Service(instantiate Entity Repository)
WEB
Entity Controllers (instantiate Entity Service)
This is working but is quite hard to mantain. I was thinking to remove the Entity Repository in DAL and use directly the DataContext (if I'm not wrong, after all DbContext has been desingned to be a Repository and a Unit of Work), but that will force me to add a reference to EntityFramework.dll in my BL. Is not a big issue, but I0m not sure it is the best choice.
Any advice?
(I hope I gave enough informations, if you need more, just ask)
You can use this this and this article.
An experienced Architect does not need to go through every single step in the book to get a reasonable design done for a small web
application. Such Architects can use their experience to speed up the
process. Since I have done similar web applications before and have
understood my deliverable, I am going to take the faster approach to
get the initial part of our DMS design done. That will hopefully
assist me to shorten the length of this article.
For those who do not have experience, let me briefly mention the general steps that involved in architecturing a software below...
Understand the initial customer requirement - Ask questions and do research to further elaborate the requirement
Define the process flow of the system preferably in visual (diagram) form. I usually draw a process-flow diagram here. In my
effort, I would try to define the manual version of the system first
and then would try to convert that into the automated version while
identifying the processes and their relations. This process-flow
diagram that we draw here can be used as the medium to validate the
captured requirements with the customer too.
Identify the software development model that suite your requirements
When the requirements are fully captured and defined before the design start, you can use the 'Water-Fall' model. But when the
requirements are undefined, a variant of 'Spiral' can be used to deal
with that.
When requirements are not defined, the system gets defined while it is being designed. In such cases, you need to keep adequate spaces
in respective modules, which later expansions are expected.
Decide what architecture to be used. In my case, to design our Document Management System (DMS), I will be using a combination of
ASP.NET MVC and Multitier Architecture (Three Tier Variant).
Analyze the system and identify its modules or sub systems.
Pick one sub system at a time and further analyze it and identify all granular level requirements belonging to that part of the systems.
Recognize the data entities and define the relationships among entities (Entity Relationship Diagram or ER Diagram). That can
followed by identifying the business entities (Some business entities
directly map with the classes of your system) and define the business
process flow.
Organized your entities. This is where you normalize your database, and decide what OOP concepts and design pattern to be used
etc.
Make your design consistent. Follow the same standards across all modules and layers. This includes streamlining the concepts (as an
example, if you have used two different design patterns in two
different modules to achieve the same goal, then pick the better
approach and use that in both the places), and conventions used in the
project.
Tuning the design is the last part of the process. In order to do this, you need to have a meeting with the project team. In that
meeting you need to present your design to your team and make them ask
questions about it. Take this as an opportunity to honestly evaluate/
adjust your design.