Currently I am creating an activity diagram for adding a new element.
The last step is that the application shows a list with all elements including the new one. But from what I've learned the diagram has to terminate on user side, therefore I am searching for a good last step.
Things which came in my mind so far (on user side):
Sees new element on screen
Sees all element including the new one (maybe way too long)
Sees a list of all elements
This is my diagram so far, feel free to improve it!
Your activity diagram gives the reader no clue about the usecase that you are describing. It is very generic from a business perspective and may be applicable for any kind of entity.
Once you embed the handling of such entity in a concrete business use case, you'll find it easy to reference a "next step" where such newly created entity is used. For example, say your new element is an address. Then that address would be used in a context. Such as: Start navigating to that address. And that could be described in another diagram.
If you want to keep it that abstract, you could introduce some abstract action such as "verify results" or "proceed to next step" which at least implies that the newly entered information will be used later in some way or another (= benefits someone).
Related
I need to start using JIRA for estimation and came across a scenario I have not found a good solution for yet. Consider an installation with more than one project which is already populated with many existing issues. Many of these issues are linked to other issues (not necessarily in the same project).
How can we configure a special link (say "parent of") and fields to record both effort estimate and logged work so that when any of the "children" are updated, some special field in the parent gets updated to reflect the corresponding aggregated values?
Just to be clear here, two issues A and B may be linked in more than one way (e.g. "parent of", "duplicate of", "relates to", "depends on", etc). However, aggregation of the special fields should only happen for a specific type of link. You can see the point when you think of the "duplicate of" link which clearly should not be aggregated.
Task & Sub-Task has exact same behaviour. Logging work in Sub-Task updates Task's work log counter.
First of all, i am not sure if such games come under "Text based games". Previously when i asked same question, i remained with doubts that probably, my question was misunderstood. Might be because of the wrong terminology i am using. So added up a video for a dummy game aimed to be built.
The game is about, competing in the "TV world" by creating more and more successful programs. It also involves planning them, hiring tv actors, managing funds etc. ( Something similar on the lines of Hollywood Mogul)
www.youtube.com/watch?v=D8C3kJ4CraQ
I tried to code the above game using MVC. However, as and as i coded, i ended up myself with a huge number of "view" classes, which was very hard to manage especially because in this particular scenario, every step take in the view, is dependent upon the another view. That is to say, there is a lot and lot of validation on each and every step.
For example, if i click on some tab, coming on the later stages of the game, it validates the data (model) collected by other prior views. This makes it very hard to code. As already the validations jumble up together, in addition to the long route followed by MVC to validate views.
Any ideas, experience shared would be appreciated. Thanks :)
The views should depend on the model, not on other views. For instance, the warning "Please specify the roles first" should occur because the model lacks the roles, not because the roles view has not been validated.
Therefore yours views should be hierarchical. You will have a main view including the top menu, for each item another view including the secondary menu and a view per form. Each form view will fill a part of the model directly. The forms views should not include the menus. There, the conditionnal validations for the top menu would only be put in your top view and so forth.
I hope this all makes sense and helps you.
I wonder what sort of things you look for when you start working on an existing, but new to you, system? Let's say that the system is quite big (whatever it means to you).
Some of the things that were identified are:
Where is a particular subroutine or procedure invoked?
What are the arguments, results and predicates of a particular function?
How does the flow of control reach a particular location?
Where is a particular variable set, used or queried?
Where is a particular variable declared?
Where is a particular data object accessed, i.e. created, read, updated or deleted?
What are the inputs and outputs of a particular module?
But if you look for something more specific or any of the above questions is particularly important to you please share it with us :)
I'm particularly interested in something that could be extracted in dynamic analysis/execution.
I like to use a "use case" approach:
First, I ask myself "what's this software's purpose?": I try to identify how users are going to interact with the application;
Once I have some "use case", I try to understand what are the objects that are more involved and how they interact with other objects.
Once I did this, I draw a UML-type diagram that describe what I've just learned for further reference. What happens after depends on the task I've been assigned, i.e. modify the code, document the code etc.
There is the question of what motivation do I have for learning the new system:
Bug fix/minor enhancement - In this case, I may focus solely on that portion of the system that performs a specific function that needs to be altered. This is a way to break down a huge system but also is a way to identify if the issue is something I can fix or if it is something that I have to hand to the off-the-shelf company whose software we are using,e.g. a CRM, CMS, or ERP system can be a customized off-the-shelf system so there are many pieces to it.
Project work - This would be the other case and is where I'd probably try to build myself a view from 30,000 feet or so to know what are the high-level components and which areas of the system does the project impact. An example of this is where I'd join a company and work off of an existing code base but I don't have the luxury of having the small focus like in the previous case. Part of that view is to look for any patterns in the code in terms of naming conventions, project structure, etc. as this may be useful once I start changing some code in the system. I'd probably do some tracing through the system and try to see where are the uglier parts of the code. By uglier I mean those parts that are kludge-like and may have some spaghetti code as this was rushed when first written and is now being reworked heavily.
To my mind another way to view this is the question of whether I'm going to be spending days or weeks wrapping my head around a system like in the second case or should this be a case where it hopefully takes only a few hours, optimistically that is, to get my footing to make the necessary changes.
In Jira, linking items together is easy and useful.
For example, you can clone an issue easily: Create issue 100, clone it to 101. 100 then shows "this issue has a clone: 101" and 101 then shows "this issue is a clone: 100"
Similarly, you can mark issue 201 as being duplicate of 200 (reverse is 200 is duplicated by 201), and there are a few other link types.
My question is around the use of related tickets. One side of the relationship is marked "This issue is related to ..." and the other side says "This issue is a relative of ...".
How does your dev team define those two items? It wouldn't matter much except the display is different, making the link types slightly different and it just looks like they are different when one issue is "a relative of" a few other issues, but also is "related to" some others....
In JIRA, links are directed, i.e. not symmetrical. One part of the link is the "source", with one role, like "duplicates", the other is the "target" with another role - "is duplicate of".
When you have a symmetrical link semantics, like issues related to each other, this just does not work well. You can name both roles equally ("is related to" -- "is related to"), and this will work to some extent. You can expect "is related to" appear twice where you select a link type, for example.
In your JIRA configration, this probably lead administrators to define the roles for the "related" link type differently. But I guess this is more a bug than a feature, and you can safely ignore the differences between two names of the same relationship.
An example of link that we implemented is
Feature <-- describes --> Epic <-- details --> Story
A feature request is something that gets planned in a release.
The feature is described by a number of high level epics.
Stories are used to provide the details of these epics. Stories
are 'INVEST'
The link relationships are
Describes
x 'is described by' y
y 'describes' x
Details
x 'is detailed in' y
y 'details' x
Drawing a entity relationship model and naming the relations is helping a lot to develop the issuelink definitions.
Francis
Facing the very same question I've read seredas answer and it is explaining the background of directed links vs. symmetrical semantics nicely (+1) - interestingly though this explanation led me to a different conclusion for practical use in JIRA:
As Steve Melnikoffs comment correctly puts it, it comes down to how the reader interprets the text, here is how I do now: while Relation has the least specific link semantic, kind of a catch all link in absence of a more specific one, there is usually still one issue (the source) triggering this relation to another one (the target), and this fact is visible in the JIRA UI by listing the the active participants of a link in the left column and the passive ones in the right one.
I've checked this conclusion against a couple of projects I'm participating in, and I'd confirm this impression now, i.e. trying to apply relates to from that angle makes the participating issues a bit easier to interpret for me at a glance.
I have encountered similar feature in JIRA lately and I must say I was pretty much convinced that there's no feature hidden behind. I can understand the need of addressing the orientation of the relation between two task theoretically .. but practically it might not be that relevant because from my experience if you work with task tracking system on regular basis, you begin to ignore the features without any noticable effect very quickly.
.. what interests me is whether there's any plugin for JIRA that bases its functionality or UI on this attribute of relation orientation.
It really depends on the interpretation you and your teams agree upon.
In our JIRA we found the default "relates to" labels to be too ambiguous, so we modified the default inward & outward labels to read "relates to" and "is related to" to distinguish link direction, while agreeing that the issues are related in a nature that can only be understood by reading both issues on a case-by-case basis, and that the direction only indicates from which issue the link was created and means nothing more. Even with these changes, we have found that this link type doesn't actually provide much meaning beyond serving as a sort of reminder depending on context. Recently we created several new issue link types to more concretely indicate the nature of related issues, serving us /much/ better.
If you want to dive a little deeper into issue links and the default issue link types in JIRA, we have published some info here.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I have read a lot of articles on Dependency Injection as well as watched a lot of videos, but I still can't get my head around it. Does anyone have a good analogy to explain it?
I watched the first part of the Autumn of Agile screencast and still was a little confused.
Analogy? I'll give it a whack... Your CD Player stereo is useless without a CD with music on it... (It's dependent on the CD). If they built CD Players with the CD already in it, it would get boring very quickly...
So they build them so you can "inject" the CD, (on which it is dependent) into the player. That way you can inject a different one each time, and get "different" behavior (music) dependent on which one you inject.
The only requirement is that the CD must be compatible with the interface defined by the player. (You can't play a blue-ray disk in a 1992 CD player.)
The best analogy I can think of is that of hiring a mechanic.
Without dependency injection, you hire a mechanic and the mechanic brings his own tools. He may have lousy tools, he may have great tools, he may be using a pipe wrench when he should be using a socket. You don't know, and may not care, so long as he gets the work done.
With dependency injection, you hire a mechanic and you provide him with the tools that you want him to do his work with. You get to choose what you consider to be the best or most appropriate tools for the work you are hiring him to do.
Think of it as a realisation of the "Inversion of Control" pattern. I guess, your problem is, you are so used to it, you don't realize it's that simple.
Let's start at the beginning.
In the early days programs followed a given path through the code. The order of the called functions was given by the programmer.
In interactive programs, e.g. mostly ANY program, you can not say, which function is called at what time. Just look at a GUI or website. You can not say, at what time what button or link is clicked. So the "control" of what's happening is no longer at the program, it's at an outer source. The "control" has been inverted. The function is no longer "acting" it is instead "listening". Think of the hollywood principle: "Don't call us, we call you". A listener is a good example for a realisation of this pattern.
IoC is realized by functions or "methods" in the "object oriented world" of today.
"Dependency Injection" now means the same, but not for "methods", which do something, but for "objects", which hold data.
The data is no longer part of the object holding it. It is "injected" into the object at runtime. To stay in hollywood, think of a film star, playing golf to talk about the business, but to keep in shape, she hungers herself down, minimizing her muscle weight and therefore she is only able to carry one club at a time.
So, on the golf course her game would heavily depend on the one club, she is carrying.
Lucky for her, there are caddies, carrying a whole lot of clubs at one time, and also having the knowledge what club to use at what time. Now she is independent of her limited possibility to carry golf clubs. "Don't think about a concrete club to wear, we know them all and give you the right one at the right time".
The film star is the object and the golf clubs are the members of the object. That's dependency injection.
Maybe focus on the "injection" part? When I see that term, I think of syringes. The process of pushing the dependencies of a component to the component can be thought of as injecting into the component.
Just like with the body, when there is something that it needs in the way of medicine (a component that it needs) you can inject it into the body.
In their 2003 JavaPolis presentation (slides), Jon Tirsén & Aslak Hellesøy had an amusing analogy with a Girl object that needs a Boy to kiss. I seem to remember that the BoyFactory is sometimes known as a 'nightclub', but that's not in the slides.
Another analogy: let us say you are a developer and whenever you like you order computer science books from the market directly - you know the sellers and their prices. In fact your company might have a preferred seller and you contact them directly. All this works fine but may be a new seller is now offering better prices and your company wants to change the 'preferred' seller.
At this point you have to make the following changes - update the contact details (and other stuff) so as to use the new seller. You still place the order directly.
Now consider we introduce a new step in between, there is a 'library' officer in the company and you have to go through him to get the books. While there is a new dependency, you are now immune to any changes to the seller: either the seller changes mode of payment or the seller himself is changed, you now simply put an order to the librarian and he gets the books for you.
From Head First Design Patterns:
Remember, code should be closed (to change) like the lotus flower in the evening, yet open (to extension) like the lotus flower in the morning
A DI-enabled object can be configured by injecting behaviors defined in other classes. The original object structure doesn't have change in order to create many variations. The injection can be made explicit by having a class request other worker-classes in its constructor, or it can be less obvious when using monkeypatching in dynamic languages like Python.
Using an analogy of a Person class, you can take a basic human framework, pass it a set of organs, and watch it evolve. The Person doesn't directly know how the organs work, but their behaviors confirm to an expected interface and influence the owner's physical and mental manifestation.
A magician's sleight of hand! What you may think you see may be secretly manipulated or replaced.
Life is full of dependency injection analogies:
printer - cartridge
digital device - battery
letter - stamp
musician - instrument
bus - driver
sickness - pill
The essence of Inversion of Control (of which Dependency Injection is an implementation) is the separation of the use of an object from the management thereof.
The analogy/example I use is an engine. An engine requires fuel to run, i.e. it is depdendent on fuel. However, the engine cannot be responsible for the fuel it needs. It just 'asks' for fuel, and it is provided (typically by a fuel pump in a car).
The analogy starts breaking down when you look too deep, in that an engine doesn't ask for fuel, it is given it by some kind of management element, like an ECU. One might be able to compare the ECU to a container but I'm not certain how valid this is.
Your project manager asks you to write an app.
You could just write some code based on your career experience so far, but it's unlikely to be what your PM wants.
Better would be if your PM dependency injected you with say a spec for the app. Now your code is going to be related to the spec he gives you.
Better if you were told where the source repository was.
Better if you were told what the tech platform was.
Better if you were told when this needed to be done by.
Etc..
I think a great analogy is a six-year-old with a lego set.
You want your objects to be like the lego bricks. Each one is independent of all the others, and yet offers a clear interface for connecting them to the others. When connecting them together, it doesn't really matter exactly which two bricks you hook together so long as they have a matching interface.
Your dependency injection framework is like the six-year-old. He follows the instructions (i.e., your config file, annotations, etc.) to connect specific bricks together in certain ways to make a particular model.
Of course, since the bricks' interfaces are pretty generalized, they can go together in lots of different ways, so it's easy to come up with new sets of instructions which the six-year-old can use to make a completely different model out of the same bricks.