what is the relation between semantic interoperability and upper ontology?
A couple of points :
You don't mention how it will automatically perform the validaty checking.
I dont agree with this statement
"This tells use that it is actually impossible to define most of English words using English alone"
An Ontolology should do presicely that - the tricky bit is to work out which one to use (there is a list of 18 top level Upper Ontologies at http://www.acutesoftware.com.au/aikif/ontology.html)
You need to clarify exactly what outputs this system is going to produce. I understand the idea of mapping the entities regulations ,etc but what are you going to do with this and how will the information be used.
Related
I have been trying to understand it but I couldn't. Can someone explain this shortly? Is there some problem with this UML diagram? If there is, where?
I thought that instead of extending arrows there might be a generalization for the pic, video, tag names, and feeling use cases. And I think that included arrows should have been dashed. Are these true? Thank you already.
You can not understand this since it is absolute nonsense. This is some semi-activity diagram. A use case is about actor goals, not how to do something. Please give the author of that a heavy kick in the rear. Or if you not that rude as myself (being a pacifist with empasis on fist - haha) just encourage them otherwise to start learning about use cases.
As always I recommend reading Bittner/Spence about use cases.
The following aspects of the diagram violate the UML specifications:
The boundary box shall represent a system (e.g. Facebook), not a function (Add Status).
Keywords include and extend shall be written in guillemets: «include», «extend».
The «include» arrows shall be dashed.
The «include» arrows shall have open arrow-heads.
To apply the use case technique in a project, the team shall agree on a specific methodology and/or philosophy. UML doesn't offer this, it is just a language (despite some definitions in the UML specification that point in a certain direction). Therefore, I will not give my opinion on whether this is a proper way of use case modeling.
With regard to generalization versus extension: both are possible in this case. If "Add Status" would mean: add pic or add video or etc., then a generalization would be more appropriate. The extension suggests that "Add Status" means: add pic and/or video and/or etc. In other words, each extending use case extends the original with additional capabilities.
For my homework, I have to write functional requirement of a game called downfall (see Wikipedia).
We have to make this game, but with not two sides but n (any number of) sides.
In an example solution (another game), the teacher writes the functional requirements, then writes what use case they belong to.
I have created a use case diagram in which I have the player as an actor, and ChooseDial, RotateDial and EndTurn as use cases:
What I dont understand are the following:
Is the number of players functional requirement?
Is the table having two sides a functional requirement?
Is the goal of the game (getting coins from top to bottom) a functional requirement?
Is a rule like coins must reach bottom in order a functional requirement?
If they are, what use case could they belong to? Is my use case diagram wrong?
I have no idea where to put these functional requirements, because I feel like they arent part of any of my use cases.
About requirements
First, let's handle the requirement question:
A functional requirement tells something about what a software shall do. Everything related to goal, the gameplay or the rules of the game, is a functional requirement.
A non functional requirement tells something about how the software shall be, for example how accurate, how performant, how easy to use, how easy to maintain. Your narrative shows no such requirements.
About use-cases
Use case driven software development methods start with the high-level user's goals that are captured in use-cases. Personally, I see only one such goal:
Very rare usage: a multiplicity on the actor side of the use case. This says that 2 or more instances of players are involved in an instance of the use case. Of course, this makes sense only for the game as a whole, not for individual actions (like you have in your diagram).
In your diagram, you have shown 3 use cases:
is EndTurn an independent goal that the user may freely decide to chose ? No ! It's what always follows a player action. So this is definitely not a use case.
you say that RotateDials extends ChooseDials. This means that a player could ChooseDials but not rorate it. Is this a valid scenario ?
if on the other hand you'd say that ChooseDials includes RotateDials, the latter would always happen. But then, wouldn't ChooseDial not be more than just choosing a dial ? Shouldn't it then be called PlayTurn ?
I could understand that for learning purpose, you'd want to decompose the Play game in more detailed use-cases. Typically, once the players try to reach their goal Play game, this might include sub-goals of Play turn. As long as it is goal-oriented, and not too detailed, this is ok. But do avoid simple functional decomposition (it doesn't help for being more user-driven, and use-cases are not functions ). And, above all, do not misuse a use-case diagram for trying to show a sequence of activities.
Requirement traceability
The use cases do not capture the full requirements. It captures the most enssential thing: the purpose of the system and the user goals.
When writing down the requirements, it's then useful to get guided by the use-cases and their narrative, and to trace-back every use-case specific requirement.
But of course, there are some general requirements as well. These are not specific to a particular use-case. Some are even common to all use case. Mark these as general requirements (e.g. use case *).
Requirements management (RM) can be tricky indeed. A requirement like The board must have two sides seems to be more involved in the design, rather than the use case. In such cases you could relate that to the boundary rather than a single use case. That will indicate it's some "global" requirement (similar to a non-functional requirement). Usually in a project you start with a more or less strange mix of requirements mixed in user stories. The business analyst (BA) has to comb that information and come up with decent use cases (synthesize the added values). The system architect (with the BA) will then go through requirements and use cases to come up with a (business) class model.
There are tons of books and procedures describing RM. Lots of seminars too. I think if you grasp the condensed idea above you're ready to start. It's a marathon to start...
The use case should depict this situation:
A shipman can ask questions via radio to either a VL, DM or WL. Depending on the question, they need to look it up in APIC (a software tool), but this is not always the case. They all are apic operators, but depending on their role, they have their speciality that they only can access in apic.
The question the shipman asks can be about lock executions, the nautical weather, etc... but it all comes down to the same question-answer format.
Is my use case correct?
Asking a question is usually not a use case. The goal of the shipman is probably not to ask a question, but to get some answers. So asking and anwering is one use case.
When analysing the use case, several possibilities will show up, such as looking up information in the APICS-system. I would just describe this within the use case (possibly with an Activity Diagram). What is the advantage of using an extend here? (I agree with the other answer, that the arrow is in the wrong direction. Additionally it should be an open arrow).
Each goal is an own use case, even when they have much in common. After describing the essential steps of the use cases, it may save some work to look at them and find those that have a big overlap in the essential steps and then create an abstract use case containing the commonalities. But this should only be done after describing the use cases.
Always remember, that the main goal of use case analysis is to find all functional requirements for the system, especially those that are not immediately obvious. If your use cases are just wrappers of functions you already know, not much insight is gained by them.
Three issues here:
The extends arrow is the wrong way around.
Generalizations of UCs is a bad idea in general.
Just as a side note: your actors miss their legs. This way it's a Female symbol (Venus' mirror).
Let's elaborate a bit on the 2nd. Why is it a bad idea? UCs represent a single added value for an actor a system under consideration will deliver. So each UC is unique (think of unique sales propositions). Generalization of USP is only valid in a franchise. So unless you model McDonalds here, it's likely a wrong approach. Look at the main UC "ask question". Do you consider that added value from a system? I wouldn't. When looking at the bubbles behind they more look like primary use cases. So, just remove that general "ask question" and connect the bubbles behind directly with Shipman.
As always when it comes to UC questions: Bittner/Spence about UC is the best read I can recommend.
What is the technical definition of theoretical computer science? (Or, what should it be?)
What main subfields does it include, and what is the commonality that separates them from the rest of computer science?
More specifically: if some particular research has direct practical motivations, goals and outcomes but mostly involves very abstract methods, is it theoretical computer science or not?
Two examples to consider:
"Dual quaternions for rigid transformation blending" (Better mathematical representation of rotation and transform for animation)
https://www.cs.tcd.ie/publications/tech-reports/reports.06/TCD-CS-2006-46.pdf
"Relational Semantics for Effect-Based Program Transformations
with Dynamic Allocation" (Complier optimisation via denotational semantics): http://research.microsoft.com/pubs/67977/ppdprelational.pdf
[The Wikipedia article gives only a vague definition and a long list of subfields. Should just accept that there's no better definition than this? http://en.wikipedia.org/wiki/Theoretical_computer_science ]
EDIT: I guess this question comes down to "What does the term 'theory' mean in the context of computer science?". Looking at the 6 different meanings of the word at wiktionary, I don't think any of them fully fits. I guess the mathematical sense of a theory fits well for completely mathematical fields but not for others, and for VLSI, machine learning and computational biology from wikipedia:TCS it basically doesn't fit.
I think the easiest way to distinguish theory from application is to look at the field's definition of a computer. If work in the field is based on the assumption that a computer is a physical object or system, then it's probably application. On the other hand, if work in the field is based on the assumption that a computer is an abstract (usually mathematical) object, it's probably theory. So, when you decide whether to say you are a theoretical computer scientist, I think you just have to ask yourself, "what is a computer?"
(For me, it's definitely an abstract object)
This link contains a list of subfields: http://arxiv.org/corr/home, I won't reproduce them here as the link may change, and it would be redundant.
Also, I'm reminded of the quote of someone, can't remember who, along the lines of:
Mathematics is whatever
mathematicians do
It would seem to apply.
There are phonetic level, syntactic level, semantic level, phonological level, acoustic level,
linguistic level, language level.
Are there any other levels?
What's the order from the bottom up?
And what are they really about?
Language admits a lot of diversity, but it also obeys a lot of rules (though often loose ones, with tons of exceptions). So in a particular language, certain sounds are more likely to follow other sounds, certain words are more likely to follow others, and so on. The levels are basically the level of modeling.
Acoustic level is trying to determine which acoustic signals are useful for distinguishing human speech. It tries to answer questions like, "Is this background noise or a speech sound?"
Phonological level is based on what sounds are most likely to combine together when it is trying to reconstruct an acoustic signal into a sequence of phonemes. I think this is essentially the same as the phonetic level.
The language level determines what kind of accent the user has, the dialect, etc.
At the syntactic level, you're looking at which words are likely to appear together based on the syntax of the sentence. This gets rid of words that it would have guessed based on the phonological level but would construct ungrammatical sentences.
The linguistic level as I understand it is more a matter of picking the right word (for example, which homonym our versus hour) based on the context.
At the semantic level, it attempts to model the meaning of the sentence and get rid of things that don't conform to the grammatical relations of verbs and prepositions. For example, the verb disappear takes no direct object, so if there is something in that semantic slot, there probably is an error.
The order will depend on the application really, some of them may be collapsed into each other, some may not be used at all. A conceptual hierarchy that makes sense to me is acoustic < phonological = phonetic < language < syntactic < linguistic < semantic.