Triggered by a concrete problem addressed in my previous Q a generic question arises which likes to be addressed here.
Yocto/Bitbake has the nice feature of layering meta-data which enables one to isolate some set of meta-data adoptations (additions, removals, changes of) from other contributor's adoptations. e.g. adoptations conducted by OEM to be in separate layer than those of SoC-vendor - that's an example I see, however still not convinient/confirmed if my understanding is correct.
Regarding using layers for meta-data adoptations isolation does it show any known limits. For instance me was lucky on adopting some set of meta-data this fashion. All originals are placed in vendor's .bb or in .bbappends. Are cases possible where isolation is question of adoptation isolation fisibility is open? Answer will be helpful for me while promoting here locally layers-usage as intended by Yocto. Will it be possible to make in own layer adoptations of vendor's meta-data placed in .conf files (machine, distribution, ...)?
Jethro is used Yocto version.
Stephen Newell's comment above answers my question. Thanks to Stephen.
Related
This is an interview question which was asked to me (Not a homework question). I did give an answer but I wanted some professional opinion on whether the answer I gave was relevant or not. The proper question was:
Construct an object oriented design for the UNIX || Windows directory structure?
Thanks in advance!!
Since we're talking OO, I assume he wants you to concentrate on operations and structure.
A file and a directory would implement a common interface involving common operations but would also have their own operations.
A tree structure is involved, either the directories and files could be part of the tree or (as I'd probably do) the tree could be an external structure that references the files and directories.
I'd list the common operations in the interface (delete, getSize), the file-only operations (open, read, write, ...) in the file interface/object and the directory-only operations (changeDirectory, createChildDirectory, createFile) in the directory object.
The point, however, is that this is an open enough question to ensure that there is NO correct answer, rather it's a chance to evaluate how you "Think OO". There are millions of good solutions, the bad ones would be ones that didn't identify methods and members as part of the object model.
It's also a good chance to show off your level of design skills--seeing if you can intelligently communicate your model to others (UML is amazingly helpful in this--working without UML can be like working without a common language when it comes to heavy modeling)
The OO design will look basically the same as a dual linked tree with the ability to do cross-linking between nodes of two different types, hard and soft links.
There's also a bunch of complexity added in when you start to deal with permissions and meta-data, but those things are not specifically related to the directory structure.
I saw some questions raised about the folder structure of source codes, but I never see the question about folder structure of project documentation. I googled it and still do not see many articles talk about.
Here is one http://www.projectperfect.com.au/downloads/Info/info_project_folder_structure.pdf
To quote some of its words:
"There are two broad approaches:
Organize by phase so that each top
directory is a phase. For example,
you might have directories for
Feasibility, Business Analysis,
Design etc. or whatever your phases
are called.
Organize by function so that the top
directory level are functions. For
example, Risks, Requirements, Scope,
Change Control, Development.
Most times a mix of both are used..."
So any thought about it? I believe this is also an important issue!
IMHO depending on your document management system the choice of structure for your documents may not be an issue. When looking at the problems project related documents are trying to solve you typically come to the conclusion that documents are about communication.
Different documents attempt to communicate different things (or contexts); test plans discuss how testing should/has been executed, requirements specifications discuss how the business rules should be applied, architecture documents discuss the technical components and so forth. Each of these documents might have the need for its own unique structure. For example the structure you choose for your test plans may be vastly different from the structure you need for your architecture documents.
When keeping the communication issue and the document context in mind I generally come back to these 2 key aspects.
Searchability – What is the easiest way to find the document I am looking for?
Versioning – How do I know that the document I am looking for is the most recent one?
I feel searchability is the most important thing to remember because different people call the same document by different names. For example some people call Business Requirements documents Functional Specifications. Some people call Functional Specifications use case documents. As you cannot always govern the naming convention of documents I feel finding the right document to be far more important than the folder or place in which it is stored.
So to answer your question I would simply answer by saying it doesn’t really matter which structure you use, just that you should use some form of document management system (SharePoint, Documentum, Trim, etc). The benefits are simply too great to work without one :)
I have been interested in formal methods for some time. I have used formal methods to reason about some very specific sub-areas of a few projects I have been working on. I was never able to convince other team members to try the same let alone specify an entire domain with a formal method.
One method I have found particularly interesting is Alloy. I think that it may "scale" better as foundation for an entire project because it is conceptually and notationally very close to actual programming languages. Furthermore, the tools are quite solid so that the benefits of model verification are readily available.
I'd be very much interested to hear about any real-world experiences you folks might have had with using Alloy in your projects. Do you feel that it has helped you in designing a better domain model? Did find errors in your domain model during verification? Would you use it again?
I've used Alloy on a few projects and have found it helpful; on some but not all of those projects I have been able to persuade others involved to use Alloy as well, or at least to work with the Alloy models I wrote. These projects may or may not be what you have in mind in asking for 'real-world' projects, but they certainly took place in the part of the real world I work in.
In 2006 and 2007 I created a partial Alloy model for the then-current draft of the W3C XProc specification; as far as I could tell, most members of the working group never read the paper I wrote (at http://www.w3.org/XML/XProc/2006/12/alloy-models/models.html); they said "Oh, we changed that part of the spec last week, so what the model says is no longer relevant". But the paper did manage to persuade the editor of the spec that the abstract 'component' level described in the first draft of the spec was woefully underspecified and needed to be either fully specified or dropped. He dropped it, with (I think) good results for the readability and usability of the spec.
In 2010 I made an Alloy model of the XPath 1.0 data model, which uncovered some glitches in the specification. The reaction of most interested parties (including the W3C working group responsible for maintaining the XPath 1.0 spec) has, unfortunately, not been encouraging.
A research project I'm involved with has used Alloy to model the MLCD Overlap Corpus, a collection of sample documents and related information we are creating (hyperlinks suppressed at SO's insistence); the Alloy model found a couple of errors in our initial design for the corpus catalog, so it was well worth the effort.
And we have also used Alloy to formalize some modeling work we have done on the nature of transcription and on the extension of the type/token distinction to document structure (for our paper, look for the 2010 proceedings of Balisage: The Markup Conference). This lies a little bit outside Alloy's usual area of application, as it has nothing to do with software design, but Alloy's ability to check models for consistency and generate instances has been invaluable in showing us some of the logical consequences of this or that possible axiom for our model.
To answer your specific questions: yes, Alloy has helped me specify cleaner domain models, and yes, it has found errors and glitches. They have often been small, for the reasons Daniel Jackson explains in his book Software Abstractions: first, if you use models during design, you catch errors early, when everything is still small. And, second (in Jackson's words), "In hindsight, most software design issues are trivial."
He continues: "But if you don't address them head-on, trivial issues have a nasty habit of becoming nontrivial." My experience amply confirms this. Much better to head off such problems early. So yes, I will use Alloy again.
Yes, I've used Alloy and it's cousins industrially. Alloy has been most helpful in convincing me that my models weren't wildly wrong---or rather, showing me where they were wrong and gave rise to silly results. Other more specific tools, like Song's Athena and Guttman and Ramsdell's CPSA have been more useful in their narrower domains. What more would you like to hear about?
Belatedly adding to this thread... Eunsuk Kang has recently applied Alloy to perform security analyses of web APIs for some start ups (following many applications of Alloy in security such as Apurva's analysis of OAuth and Barth et al's analysis of browser based security mechanisms for CSRF etc); Pamela Zave has been working on an impressive analysis of Chord, a peer to peer storage system, and has recently written up a fix to the original algorithm.
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 5 years ago.
Improve this question
As we know UML contains 13 types of diagrams (structural and behavioral)
before starting a software developement, we are in requirement and design phase so which diagram should be create and when? .. What should be the sequence of diagrams creation in UML in requirement and design phase?
In fact if there is no rigid sequence then first we need to create structural diagram rigidly but the behaviour like Activity diagram may change according to user experience?
Can we create a deployment diagram and component diagram as one only?
There's absoultely no rule regarding the sequence of such diagrams.
Sometimes, when the structure of the data and the behavior of your domain model is easily defined or well documented, creating the class diagrams first allow for clearer abstractions that aid in creating a sequence diagram that makes sense.
In other cases, when the nature of the domain model is unknown or unclear, it will make more sense to create a sequence diagram first, and then glean classes from that.
What I am sure of is that revisions of these diagrams will become concurrent with each other (e.g., sequence diagrams may reveal something that wasn't taken into account for in the class diagrams, and vice versa).
Likewise, after starting software development these diagrams may change yet again, as more intuitive, or more maintainable abstractions and designs reveal themselves whether via unit tests or user-experience testing and so on and so forth.
Never get enamoured with the idea that these diagrams are rigid in any way and thus requires a sequence in creation -- trust me, they won't be. If you treat them as rigid and infallible, you're shooting yourself in the foot AND tying one arm behind you in your software development effort.
UPDATE As reflected in the comments, if you're really lost as to what diagram to go first with, the Use Case Diagram would be very important as early as the requirements gathering phase.
Beyond that, what I wrote above applies.
I agree with Jon and Pete, but respectfully add that UML is the what and the how varies.
There are processes like OOA and OOD (OOAD) which describe the how and what is UML. The wiki articles helpful, but it works more like this. Many RUP processes developed also involve the how of UML.
A standard set of orders for a user involved project (again use what you need):
1. Use Case (Focused on User/System Interaction.
2. Activity/Sequence that drills into the Use Cases.
3. Component/Interface diagram if you are connecting systems.
4. Package/Class if you are doing a large OO build.
5. Deployment to show what goes where in the infrastructure.
Nothing magical about the model/diagram elements I listed above but this seems to be the common set.
In fact if there is no rigid sequence then first we need to create structural diagram rigidly but the behaviour like Activity diagram may change according to user experience?
Form follows function. If you need to change the behaviour, there's a good chance you need to change the structure from which that behaviour emerges.
Usecase analysis is an effective way to capture the goals from the requirements. Use the usecase descriptions to identify your domain objects and produce a domain model. I find CRC useful at this stage even though it not official UML. Once I have produced my domain model I produce a Sequence Diagram for each usecase. Though Activity diagrams are also a useful alternative. I resolved the Domain model into a more detail class model. At this stage it is straightforward to produce a deployment model.
I am currently trying to draw a set of UML diagrams to represent products, offers, orders, deliveries and payments. These diagrams have probably been invented by a million developers before me.
Are there any efforts to standardize the modeling of such common things? Or even the modeling of specific domains (for example car-manufacturing).
Do you know if there is some sort of repository containing UML diagrams (class diagrams, sequence diagrams, state diagrams...)?
There is a movement for documenting (as opposed to standardizing) models for certain domains. These are called analysis patterns and is a term Martin Fowler came up with. He actually wrote a book called Analysis patterns. Also, he has a dedicated section on his website where he presents some of these patterns accompanied by UML diagrams.
Maybe you'll find some inspiration that will help you in modeling your domain. I've stressed the word inspiration as I think different businesses have different requirements although they operate the same domain so the solutions you might read about may not be appropriate for your problem.
There are many tools out there that do both - but they're generally not free!
Microsoft Visio does both and is extensible. For UML artefacts they come with auto generators into VB/Java template code - but you can modify them to auto-generate any code. There are many users of Visio that have created models from which to use as templates.
Artisan Enterprize is by far the most powerful UML tool (but it's not cheap).
Some would argue that Rational Rose or RUP is the better tool
But for Car-Manufacturing and other similar real world modelling, by far the best tool is Mathworks Simulink (not because it's one of the most expensive). It is by far the best tool beccause you can animate the model - you can prove the model working before generating the slik code (in whatever grammar/language/other Models you care to push it)!
You can obtain a student license for around £180; with the 'real thing' pushing £4000 (for car-related artefacts). The full product with all the trimmings is about £15k. Simulink is also extensible with a C like language though there is a .Net addin and APIs to use a plethora of other langhuages. And, just like Visio there is a world-wide forum creating saleable, shareware & freeware real world model templates. Many world-wide Auto-Manufacturers are already using Simulink.
I think that MiniQuark question is really good and will sooner or later be provided by vendors such as Omondo, Rational IBM etc... Users doesn't just need tools, they need models out of the box and just add their business rules inside an existing well defined architecture. Why to develop from scratch a new architecture if the job has already be done ? In Java we use plenty of frameworks, existing methods etc...so why not to go one level higher and reuse architecture ? It is today impossible to guess how a project will evole and new demands are coming every day. We therefore need a stable architecture which has been tested previously and is extensible. I have seen so many projects starting with a nice architecture then realizing in the middle of the project that this is not what is the best and then changing their architecture. Renaming classes, splitting classes, creating packages etc...after the first iteration it is getting a real mess. Could you imagine what we found after 10 iterations !! a total mess !!
This mess would had been avoided if using a predefined model which has been tested previously because the missing class, or package etc..would have already been created and only a class rename would be sufficient for architecture purposes. Adding business rules methods will end the codding stage before deployment test.
I think there is a confusion between patterns and the initial question which is related to UML model re usability.
There is no today any reusable model out of the box which has been developped. This is really strange but the job has never been done or never been shared.
Omondo has tried to launch an initiative without real success. I have heard that they are working on hundred of out of box models which will be open source and given for free to the community. I hope this will be done because this is really important for me and would save me a lot of time at the beginning of a project.