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
Say we are creating Acme CMS. This CMS web application will allow you to create an unlimited number of categories with sub-categories (unlimited depth), and each category can have 0+ content pages associated with it.
So this project, at a high level will have:
Front End
1. index page
2. category page with list of content pages
3. content page
Admin Control Panel
1. categories (add/update/delete)
2. pages (add/update/delete/)
Schema design
1. tables
2. stored procedures
3. data access layer
Questions:
I am using a bug tracker and Wiki, so how should I break this project down?
I am thinking of breaking each section (front end/ admin panel) down into individual pages, then writing simple user stories for each page (or theme).
When I have the user stories completed, I will then create a list of cases in my bug tracker representing features that I have to develop, along with an estimate for each one.
Am I breaking down this project properly? Any major gaps in planning that will make this project fail (in theory anyway!)
Please provide a detailed answer, maybe a general idea of what I should do, with a detailed example explaining it and why etc.
"I am thinking of breaking each section (front end/ admin panel) down into individual pages, then writing simple user stories for each page (or theme)."
Pages don't have stories. Users have stories. Pages are a thing you build to implement the user story.
The Theme -- if there is one for something this small -- is "managing content". Perhaps there are two themes: the collection of stories about writing/editing and the story(s) around browsing/reading.
Some users ('editors'?) want to create, organize, update and remove content so they can something [the question doesn't say]. You force them to use web pages because it's better - cheaper - faster than 5x8 cards and markers.
Some users ('readers'?) want to examine content and navigate so they can -- who knows? -- be happier and more productive at something. You force them to use web pages because it's somehow better than 5x8 cards held to a whiteboard with magnets.
You have stories about the theme of creating and managing content.
"then create a list of cases in my bug tracker representing features that I have to develop, along with an estimate for each one"
Right. And the features have to begin with data model first, then presentation in some useful form. Perhaps on pages. Indeed, once you have a model that satisfies the use cases in a broad way, you can fine-tune the presentation to make the model more usable.
"business layer & presentation is what I need to detail"
Model == business layer. They're the same thing.
Pages == presentation. Note. This is last. Once you have use cases and a model that supports those use cases, you can present your stuff to people so they can interact with the model.
As far as I can see you've got a few glaring gaps in your design, part of the features is implied (linking of categories and pages) and some are left out altogether (login for administrators, user management, preview etc). These are going to make up about half of your small application, and you better include them into the initial outline. Perhaps you may want to take a more systematic approach to designing the CMS. And there are at least three general routes you could take:
Design a domain model first, and then design business layer, then UI and data model.
Start with data model and build business layer and UI on top of it.
Model the UI first, then everything else.
Regardless of which path you would prefer to take (or combination of) there are some general guidelines:
Start with a big picture of work you want to automate. This is called “work scope”. “Big picture” here can be meant quite literally and although it can be a just a story describing the process, it is best to visualise using a rich picture that includes actions, artefacts, other applications, users etc. As for the “big” part of the equation the picture needs to encompass more than the intended product, be bigger than the segment of work you want to automate.
Then outline what specific work you want your product to take care of. This is usually referred to as “product scope”.
Make a list of user roles (or profiles) for your application, list of inputs and outputs, list of external interfaces.
Now you may want to start writing some user stories. You’ll need at least one per user profile, since you need to provide an illustration of all user perspectives.
At this point there going to be just enough information at your disposal to start a more precise modelling of the problem using either domain model, or UI model or data model, whichever you fancy or feel more comfortable with.
All of the steps are very much iterative. Once you understand a bit more about the application, its wider context and have a list of features that need to be implemented to meet the requirements you’d be in the position to give some very rough estimates and then go through a prioritisation process.
Needless to say that this is just a simplified framework and many software developers would take a different approach to designing an app, depending on their skills, needs, preferences etc. But it could be a good starting point to a more systematic evaluation of the problem you want to solve.
The "unlimited" part is broken... even GMail has an upper limit...
Edit: Although my answer got downvoted I think it is right. As soon as you talk with non-programmers the "unlimite" parts become very dangerous, and will likely stab you in the back. Also you can't really have a scalable data schema for unlimited nesting... but that should be obvious.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have been working for a while now but because of my earlier habits i never worked systematically.
I have never created a workflow chart for my software as how the software will work and instead of that i started working directly which in turn leads to many problems later.
Below is a small situation i currently need help with:-
NOTE:I have already created a software which does the following and i don't need any code for it, i just want to know how a workflow chart is created for such a situation.
1) Party List : This is where i would like to store all of the information of my customer.
2) Sales : Here i will sell my products to the customer.
There are 2 cases here, whenever the customer arrives we have an option to
either save it in the party list and select it from the list in the sales form
or type it manually and then save it
Now comes the checking part:-
If an entry was saved in Sales when the checkbox was ticked and the user selected a party, lets say "Akhmed" has been saved AND the user tries to delete the record of "Akhmed" from the Party List form then the software shouldn't allow it to do so as the entry of "Akhmed" already exist in Sales.
Can anyone show me how a workflow chart is created for such a situation?
EDIT
Here is a sample workflow i have made after reading some articles, please point out any improvements that can be made to it or is it completely wrong or anything.
First of all, great question. I wish all software engineers thought first before jumping to writing a code. Especially when it's about anything more serious than a couple of lines for fun.
I think your software flow can be expressed as Activity diagram. An example of activity diagram is expressed on this picture: https://www.tutorialspoint.com/uml/images/uml_activity_diagram.jpg
Basically, activity diagram is a combination of steps and transitions (arrows) connecting them. Step can be just something that happens in the flow, or it can be a logical operator (decision) which branches the flow execution into different directions.
If you need to also emphasize who needs to execute the step, besides just showing what the steps are, you can add swimlanes (horizontal or vertical columns showing the actor names) to the activity diagram. That's where it turns into a Flow Chart diagram. e.g. on this image you can see horizontal swimplanes explaining who does the step execution http://static1.creately.com/blog/wp-content/uploads/2011/11/Support-Process-Flowchart-Template-1024x613.png
Note that terminology can differ from person to person, but these are the names for these 2 kinds of diagrams I have mostly heard and used myself.
There are other kinds of diagrams too, but I think your specific case will be covered with the ones mentioned above. Although... use case diagram can be something you may be interested in, but that does not depict steps. That only will mention actors and what kind of actions they can do with your system. e.g. https://sourcemaking.com/files/sm/images/uml/img_32.jpg
You didn't ask for tools, but I usually prefer to use tools that are rigor (rather than loose like Visio), so I would recommend to use WhiteStarUML. It's free and does a great job. But as I said, it's strictly UML-based, so will require some familiarity with UML.
Finally, about your attached picture:
What you showed looks like an activity diagram with some illegal components on it (illegal from UML specification standpoint). Is it good or bad? - depends. If it's supposed to be a rigor UML diagram then it's bad. If it's just a sketch of an idea - not bad.
Your diagram mentions database sign (called "DB") and arrows connecting to it. That's illegal on an activity diagram UML. Instead, you can have a step which says "Data gets saved to Database", and remove the "DB". Also, you have a single step which says both "Party" and "Sales" on it - that's not a legal UML. I think you tried to express that there are 2 flows. In that case, just have 2 different activity diagrams instead of one.
Your question is quite broad but I'll give it a shot.
I think you want to reconsider your approach. I would suggest reading up on UML sequence diagrams. They are a kind of diagram that provides a way to represent how requests are made within code. UML, in general, can also be used to make class diagrams and other useful flow-like charts for representing code. Many tools, such as visual-paradigm, allow you to build UML diagrams (ex. class diagrams)that can be converted directly into code. This can be useful when getting you started on the program. There is a learning curve with using these tools as different kinds of arrows mean different things, but they can be very powerful. they can also be used to take existing code and convert it to a diagram, which is great when trying to explain how your program works.
here are some other links that might be useful:
lucidchart has an example of a pop-up window diagram like the one you described.
draw.io just allows for you to make the diagrams, not convert them to code, but it is an easy to use tool and integrates with google drive and git hub.
stackoverflow has some info on UML too.
If you are looking for a "professional workflow diagram" UML if a fine way to go, there are many ways they can be laid out and they can be quite professional, I learned about them in school and have used them at work to help plan out the flow of data through our system. There are many more UML tools out there, it might be worth looking into a tutorial to find what's best for you.
You seem to be on the right track, I have never added a database to my flow-charts but it is up to you on how detailed you want to get. You seem to be using the correct symbols!
Here is an awesome, free website that I use. https://www.draw.io/ it was created for making flow charts and other things.
I personally would remove the UI at the beginning of your chart. Try to stay away from the overly technical examples when starting out with flow-charts, hit up YouTube or Google images for some simple, but correct examples.
Good luck friend!
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I'm starting a new project from scratch and have written User Stores to describe how a given user will interact with the system. But, I'm having trouble understanding how to break the first user story in to tasks without the first one becoming an epic.
For example, if I were building a car and the first user story said something like "As a driver, I would like to be able to change the direction of motion so that I don't hit things.", that would imply a user interface (steering wheel), but also motion (wheels) and everything necessary to link those together (axle, frame, linkage, etc...). In the end, that first user story always seems to represent about 40% of the project because it implies so much about the underlying architecture.
How do you break user stories down for a new project such that the first one doesn't become an epic representing your entire underlying architecture?
You might want to think of your story as a vertical slice of the system. A story may (and often will) touch components in all of the architectural layers of the system. You might therefore want to think of your tasks as the work needed to be done on each of the components that your story touches.
For example, Let's say you have a story like In order to easily be able to follow my friends' tweets, as a registered user, I want to automatically follow all of my gmail contacts that have twitter accounts.
In order to accomplish this, you will have to pass through the UI layer, service layer, persist some data in the data layer, and make an API call to twitter and gmail.
Your tasks might be:
Add an option to the menu
Add a new gmail authentication screen
Add a twitter authentication screen
Add a contact selection screen
Add a controller that calls into your service layer
Write a new service that does the work
Save contacts to the database
Modify your existing gmail API calling service to get contacts
Add a twitter API calling service to follow selected contacts
There: That's 9 possible tasks right there. Now, as a rule, you want your tasks to take roughly 1/2 a day to 2 days, with a bias towards one day (best practice, for sizing). Depending on the difficulty, you might break down these tasks further, or combine some if they are two easy (perhaps the two API calling services are so simple, you'd just have a modify external API services).
At any rate, this is a raw sketch of how to break the stories down.
EDIT:
In response to more question that I got on the subject of breaking stories into tasks, I wrote a blog post about it, and would like to share it here. I've elaborated on the steps needed to break the story. The link is here.
When we started projects under a Scrum management style, the first set of tasks was always broad, or as you describe it: epic. That's inevitable, the framework of any project is usually the most important, largest, and time-consuming portion, but it supports the rest of the project. In order to pare down the scale on overwhelming-ness of how much there is to do see if you can list the MOST essential parts. Then work on defining those tasks as the starting points. Therefore you have a few tasks as starting points for a broad beginning. Hope that makes sense!
A user story describe the what while a task is more about the how.
There is no perfect formula, just add any task that describe how the user story is going to be implemented, documented or tested.
Keep in mind that a task should be estimated in hours, so try to scale and detail the tasks accordingly.
If you feel that you have too many tasks for a story (even if you have 1-8 hours long tasks), then maybe you should consider rewriting your user story in the first place because it's probably too complex.
Good luck
The story that you implement at the beginning can be refined over time. You dont need to think that every story has to be the final version that the user is going to use.
For example, in a recent project we had to develop an application which involved indexing various websites, and matching them against filters created by users, and finally alerting the user of matches (thing of it as google alert on steroids).
If you look at it from one perspective, there is only one story - "As a user I want to get alerts from matching pages". But look at it from another perspective of "what are the risks we want to mitigate". The first risk was that users wouldn't get relevant or better hits compared to google alerts. The second risk was in learning the technology to build this.
So our first user story was simply "As a user I want relevant hits", then we built just the hit matching algorithm on a hardcoded set of pages and hardcoded filters for some early users and got their feedback.
There might actually be a bit of back and forth here with multiple smaller stories to capture learning like "As a user I want more priority to be given to matches in the URL" etc.. these stories comes from the feedback as we iterate over what the early users consider "relevant hits".
Next, we broadened it to "As a user I want hits from specific websites" and we built the indexing architecture to crawl user specified sites and do hit matching on that.
The third story was "As a user I want to define my own filters", and we built this part of the system.
In this way we were able to build up the architecture piece by piece. Through most of the initial part, only early users could use the system, and many pieces of data were hardcoded etc.
After a point, early users could use the system completely. Then we added stories for allowing new users to register and opened it up to the public.
To cut a long story short, the story you implement first could implement only a small part of the final story, hardcoding and scaffolding everything else. And then you can iterate on it over time till you get the story that you might actually release to the public.
I've come to a crossroads with this issue in the past. User stories are supposed to be isolated so you can do them without any other stories, in whatever order, etc. But I found making that happen just made everything more complicated. To me this fell under the "Individuals and interactions over processes and tools" part of the agile manifesto - or at least my interpretation of it.
The ultimate goal is ship. And to ship you have to build, and to build you have to stop futzing with scrum and just get stuff done and make sure you track it.
So what we did was break a cardinal rule of stories and we made some tech stories like "create a preliminary schema". We also declared that some stories were dependent on others, and noted that on the back of the story card.
In the end I felt this type of story was few and far between, and the difficulty of the alternative justified the exception.
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
I'm a newbie to the Agile/TDD world and trying to get my head around some of the basics.
This is related to the way I should go about implementing user stories.
For e.g. lets assume I have below 2 user stories to start with for a hypothetical content management system:
Story 1:
As a Content Author
I need to be able to create News Articles
so that they can be used to attract users to the web site
Story 2:
As an Editor
I need to be able to view existing articles
so that I can review them to improve the quality
The way I would approach this is,
I would grab one of these user stories
break the I need to part of the user story into smaller pieces of tasks
Grab these tasks one by one and come up with Tests to cover the specific task
Implement tasks the TDD way
Area where my dilemma is about the As a part of the user story.
Specially in these examples they indirectly imply some Authentication,Authorization related requirments to me since the user stories mention about two user categories.
So my question is, whether I should have any tasks/tests that control Authentication/Authorization to the system to complete these user stories
Or should I only focus on the I need to part of the user stories in trying to implement the functionality, and wait for any user stories that specifically mention about Authentication,Authorization related requirments?
All your inputs are highly appreciated.
Cheers.
Worry not about the implications at this stage.
A user story should be:
I Independent The user story should be self contained, in a way that
there is no inherent dependency on another user story.
N Negotiable: User
stories, up until they are part of an iteration, can always be changed and
rewritten.
V Valuable: A user story must deliver value to the end user.
E Estimable: You must always be able
to estimate the size of a user story.
S Sized appropriately or Small: User
stories should not be so big as to become impossible to
plan / task / prioritise with a certain level of certainty.
T Testable: The user story or its related description
must provide the necessary information to make testing the development
possible.
[Source, Wikipedia]
If they haven't been wriiten yet, you can add the authorisation stories to your product backlog for the product owner to prioritise. The authorisation stories may be picked up by some other team, such as your network administration or similar, so concentrate on delivering the functionaility requested by the story that you are working on.
You should definitely focus on the I need to part and consider the As a and so that as some kind of context.
There are many loopholes in your stories. The underlying Authorization/Identification part is one, another one I see is that the so that I attract more visitors to my website is something you can't really test, so you should think again and find another one (probably something simple and not very different like so that I can put them on my website to attract more visitors). I believe that with that format the so that part should contain some rough idea of how you'll test your story.
Really I use something much less formal for my stories : a title, a short description and some explanation of how to demo. I also add some priority value (important for the product owner) and a rough estimate of the work amount. The most usefull part is probably the How to demo as it will help writing tests (after breaking the story if necessary, but I also prefer, if possible, keeping stories shorts to avoid the need to break them). Also I try not to break stories to tasks but to smaller stories. Task is often too much about how you will do something and you should focus on what result you want.
In your case, there will most certainly be other stories and one will be about authentication someday, but that should not stop you to code pages now. Just go on step by step, keep your stories simple (you have tests, refactoring later is easy) and you'll quickly get the feeling of what works for you.
You should have a look at the excellent Book Scrum and XP from Trenches and see how they do it.
The phrase
"As a Content Author
I need to be able to create News Articles
so that they can be used to attract users to the web site"
is not the story. It is a summary of the story that fits on a card or in a spreadsheet column and represents the story so you can remember which one you're talking about. The whole story is composed of three parts - Card, Conversation and Confirmation - and the part you need here is the conversation.
Talk to the user or the user representative in your team to find out what it really means.
As a part does not imply Authentication or Authorization. In the same way you can write a user story as:
As a new visitor ...
As a returning visitor ...
Does it mean that visitor has to be authenticated? What authorization vistor has? User stories should not include "hidden requirement". If you need authentication and authorization simply create user story for that.
As a part specifies type of user roles in your application. Each role has some special needs and requirements and uses application from different reason. You should try to collect roles before you start to write user stories.
A user story does not contain only description. It should contain additional information which are added in different phases of the process.
Description in defined format. You don't have to use As a ... I need ... so that ... if you think it doesn't fit your needs but you should use same format for all stories.
DoD - definition of done also known as acceptance criteria. This should be collected with description. User story without DoD is useless. DoD says developer additional information about user story. User story is completed only if it fulfills DoD. You can also create automated acceptance tests based on these criterias.
Priority set by customer - this will help you sort user stories by importance
Estimate - made by team. Estimate is not exact it should be based on comparison among user stories. Usual units of estimate is abstract story point or t-shirt size.
Also be aware that not every user story is decomposed to tasks directly. You can have big high level user story which will be first decomposed to smaller user stories. We call such user story Epic.
You could initially make the assumption that the user is authorized to make changes, then tackle the authorization as separate stories later on (when they become the most important items in your backlog).
This has the benefit of keeping the scope of your stories small so they are easier to work with, and also gets the initial stories in a potentially deployable state earlier on.
At the very least I'd spawn stories for:
authenticate user
signup Author / Editor ... or signup User, assign permissions
If no one knows how that'd be handle those at the story level, I'd talk to/grab the phone/initiate im and check with them. You can TDD your way at the lower level for the feature that you wan't to implement, but any test automation on end-to-end story should go through what the user does.
The thing with those stories is that you might be thinking in the underlying tasks, but from the user point of view you might end up finding that the client wanted more of a blog with openid/login with existing account feeling. Its agile after all, its the way it rolls / full communication instead of an all defined in a large analysis + design phase.
No point in dedicating a sec of thought to usernames/password/hashes/etc when that might not even relate to the project.
Whatever you do, keep it simple.
ps. its all an integral part of the story, it just happens to depend on other stories being in place.
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 8 years ago.
Improve this question
I ask about the pattern, not framework. This is kind of follow-up to a question on UI auto-generation.
Do you believe in the concept of UI auto-generation from metadata?
What kind of problems can be approached this way?
The question arose when I've created a small library to support my student projects, which generates interactive CLI in runtime based on object's metadata. And I think CLI it generates is quite decent.
On the other extreme is the Naked Objects Framework, which is rather universal, but UI it generates is horrible, IMO.
It's clear, every problem is specific and needs specific UI, but maybe there are several classes of problems where auto-generation is acceptable?
Yes, I believe the concept of metadata-based auto-generated applications is very sound - mainly because it drastically reduces development time and improves code quality by reducing the massive redundancy you have in most applications where each domain data field is represented in the database, in the model, in the UI, and often also several times in various mapping layers.
I think the future is auto-generated apps that can be modified wherever necessary. Currently, this is AFAIK not really possible; for example, Rails only allows you to fully customize the UI when you use static scaffolding, which basically means code generation, i.e. many further changes in the domain model are then not automatically represented in the UI because the duplication has happened when the code was generated.
I believe the first framework that manages to combine complete auto-generation with complete modifiability afterwards will become the de-facto development standard to a previously unknown degree. Though most likely we'll get there in small steps so that there will not be such a single dominating framework.
Take a look at JMatter, which is a rather better-looking implementation of Naked Objects.
http://www.jmatter.org
There is also Chris Muller's work on MAUI, and Lukas Renggli's work on Magritte (both Squeak /Smalltalk)
We have lots of generated UI in the configuration part of our apps. All those lists that are around forever and changed once in a blue moon by a system administrator.
I find that most applications with a database back-end tend to have a bad design from an OO and NO perspective, as already shown in the NO book by Pawson and Matthews.
Re: qn #1 ... Do you believe in the concept of UI auto-generation from metadata? ... I'm definitely going to answer 'yes' to your first question, being one of the committers to the Naked Objects (Java) framework and writing a book on DDD + NO.
The question mentions metadata. I think this is key to NO being able to succeed. In the latest version (which will be going beta in Feb) the metamodel has been opened up so that it is very extensible, either so you can write your domain model following your own programming conventions/annotations, or, potentially so that more sophisticated viewers can look for their own metadata to provide more sophisticated views. (For example, consider that if an object implemented a Location interface then it is displayed in a google maps).
Regarding qn #2 ... what kind of problems can be approached this way ... we've always said that NO is more suitable for "sovereign applications" (transactional, operational systems ones used internally within an organization) to "transient applications" (like an airport kiosk, say). An NO GUI does require that the user is familiar with the domain, otherwise they won't know what they are looking at.
What's missing still is sophisticated viewers, of course. You are right about the NO GUI, it is definitely low fidelity (though the .NET version is a big improvement, see recent infoq.com article). On the Java side there is a sister project called scimpi.org that has a lot of promise though... it provides a basic web GUI for free but lets you hand-craft web pages as necessary and incrementally. I'm also working on an Eclipse RCP GUI that'll work similarly.
The other thing to add to this though is that the NO approach has value (I believe) even if you choose to write a custom GUI and/or presentation layer. That is, you can use it as a design tool for building a very solid pojo domain layer, and then skin it as you will. Trouble is that NO was never originally sold in those terms, so most will see the NO pattern as an all-or-nothing affair.
Dan
One way to look at this is to consider the difference between the user interface you get from something like Toad or MySQL Browser, where the user interface is directly constructed from the tables and their associated meta data, and the user interface that a skilled designer would develop for the actual application. IF there not too disimilar then it should be fairly low hanging fruit for an auto-generation framework.
As you say there are classes of problems which will work quite well with this kind of auto generation and some which wouldn't. To my mind the key things are how well the implementation model (or portion thereof) which you are exposing in the user interface maps to the conceptual model of the user. Secondly how well can the behavior of the application can be expressed through a limited set of user interface components (assuming this is a general purpose UI generation framework).
This article "Universal Model of a User Interface" may be of interest .
I think the idea of automatically generated UIs has a lot of potential especially for your average form-and-table layout database user interface. However, even there a human needs to be in the loop, having the ability to override the output without it being overwritten with the next regeneration.
I suspect automatically generated UIs would be more successful today if interaction designers were more involved in developing the generation algorithms. My impression is that historically the creators of these systems don’t know what kinds of UI-related metadata to include or how to use it. Specifying labels, value ranges, formats, and orders for fields is a start, but more high level information is needed. Sufficient modeling of the tasks and user roles in particular tends to be lacking, along with some basic style-guide-level principles for UI.
Oracle’s Designer 2000, for example, was on the right track in including not only the entities and relations in the model, but also the tasks in the form of a functional hierarchy. Then they blew it by misapplying this metadata (e.g., assuming that depth is always preferred to breadth) and including fundamental flaws when generating the UI (e.g., only one primary window can be opened at a time). The result was IUs that were not even consistent with Oracle’s own Applications User Interface Standards.
Getting a basic UI up quickly that lets the customer try out the system and create test data must be of value. Naked Objects frameworks can help for the “boot strapping” even if you have to have replace it with “hand crafted” UI before you ship.
In most system I have worked on, there have been lots of simple housekeeping tables. All these tables need a UI to edit and view them etc. There is also great value in these simple editors being consistent. Here a naked Objects framework could save a lot of time, even if the main “day to day” UI is “hand crafted”
I have seen a couple of failed projects (cases where I was brought in as a rather expensive consultant to help architect the replacement) which used the "naked objects" approach (not the framework, AFAIK) - all with simply atrocious UIs, and worked replacing a lot of the UI on one project which, in its original incarnation, had a similar approach (the entire application was a tree of objects accessed through context menus and property sheets - this was NetBeans 2.0 circa 1998 - IDE as a giant hierarchical JavaBean).
The bottom line is, your users don't care about your architecture, they care about getting what they need to do done in the most comprehensible-to-mere-mortals set of interactions you can come up with. If that happens to align with your architecture, you are having a lucky day - but it really is serendipity. Trying to force users to care (or even know) about your architecture is a recipe for software nobody wants to use.
Code generally needs to be designed around two not-always-compatible goals:
Maintainability - people who didn't write the code can understand the code
Stability and performance - i.e. the activities the code asks the computer to physically do are both possible, and can be completed within a reasonable time frame
The abstractions and code structures that it makes sense to create to meet those two goals very, very rarely map exactly to user interface elements of any sort. Sometimes you can get away with it - barely - if your audience is technical. But even there, you are likely to please more users with at least a "presentation layer" adapter layer on top of the architecture that makes sense for programmers and machines.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I found What are mvp and mvc and what is the difference but it didn't really answer this question.
I've recently started using MVC because it's part of the framework that myself and my work-partner are going to use. We chose it because it looked easy and separated process from display, are there advantages besides this that we don't know about and could be missing out on?
Pros
Display and Processing are seperated
Cons
None so far
MVC is the separation of model, view and controller — nothing more, nothing less. It's simply a paradigm; an ideal that you should have in the back of your mind when designing classes. Avoid mixing code from the three categories into one class.
For example, while a table grid view should obviously present data once shown, it should not have code on where to retrieve the data from, or what its native structure (the model) is like. Likewise, while it may have a function to sum up a column, the actual summing is supposed to happen in the controller.
A 'save file' dialog (view) ultimately passes the path, once picked by the user, on to the controller, which then asks the model for the data, and does the actual saving.
This separation of responsibilities allows flexibility down the road. For example, because the view doesn't care about the underlying model, supporting multiple file formats is easier: just add a model subclass for each.
Separation of concerns is the biggy.
Being able to tease these components apart makes the code easier to re-use and independently test. If you don't actually know what MVC is, be careful about trying to understand people's opinions as there is still some contention about what the "Model" is (whether it is the business objects/DataSets/DataTables or if it represents the underlying service layer).
I've seen all sorts of implementations that call themselves MVC but aren't exactly and as the comments in Jeff's article show MVC is a contentious point that I don't think developers will ever fully agree upon.
A good round up of all of the different MVC types is available here.
Jeff has a post about it, otherwise I found some useful documents on Apple's website, in Cocoa tutorials (this one for example).
I think another benefit of using the MVC pattern is that it opens up the doors to other approaches to the design, such as MVP/Presenter first and the many other MV* patterns.
Without this fundamental segregation of the design "components" the adoption of these techniques would be much more difficult.
I think it helps to make your code even more interface-based.. Not only within the individual project, but you can almost start to develop common "views" which mean you can template lot more of the "grunt" code used in your applications. For example, a very abstract "data view" which simply takes a bunch of data and throws it to a common grid layout.
Edit:
If I remember correctly, this is a pretty good podcast on MV* patterns (listened to it a while ago!)
MVC is just a general design pattern that, in the context of lean web app development, makes it easy for the developer to keep the HTML markup in an app’s presentation layer (the view) separate from the methods that receive and handle client requests (the controllers) and the data representations that are returned within the view (the models). It’s all about separation of concerns, that is, keeping code that serves one functional purpose (e.g. handling client requests) sequestered from code that serves an entirely different functional purpose (e.g. representing data).
It’s the same principle for why anybody who’s spent more than 5 min trying to build a website can appreciate the need to keep your HTML markup, JavaScript, and CSS in separate files: If you just dump all of your code into a single file, you end up with spaghetti that’s virtually un-editable later on.
Since you asked for possible "cons": I’m no authority on software architecture design, but based on my experience developing in MVC, I think it’s also important to point out that following a strict, no-frills MVC design pattern is most useful for 1) lightweight web apps, or 2) as the UI layer of a larger enterprise app. I’m surprised this specification isn’t talked about more, because MVC contains no explicit definitions for your business logic, domain models, or really anything in the data access layer of your app. When I started developing in ASP.NET MVC (i.e. before I knew other software architectures even existed), I would end up with very bloated controllers or even view models chock full of business logic that, had I been working on enterprise applications, would have made it difficult for other devs who were unfamiliar with my code to modify (i.e. more spaghetti).
One con I can think of is if you need really fast access to your data in your view (for example, game animation data like bone positions.) It is very inefficient to keep a layer of separation in this case.
Otherwise, for most other applications which are more data driven than graphics driven, it seems like a logical way to drive a UI.
If you follow the stackoverflow podcasts you can hear Jeff (and Geoff?) discuss its greatness. https://blog.stackoverflow.com/2008/08/podcast-17/. But remember that using these separate layers means things are easier in the future--and harder now. And layers can make things slower. And you may not need them. But don't let that stop you from learning what it is--when building big, robust, long-lived systems, it's invaluable.
It separates Model and View controlled by a Controller,
As far as Model is concerned, Your Models has to follow OO architecture, future enhancements and other maintenance of the code base should be very easy and the code base should be reusable.
Same model can have any no.of views e.g) same info can be shown in as different graphical views.
Same view can have different no.of models e.g) different detailed can be shown as a single graph say as a bar graph.
This is what is re-usability of both View and Model.
Enhancements in views and other support of new technologies for building the view can be implemented easily.
Guy who is working on view dose not need to know about the underlying Model code base and its architecture, vise versa for the model.
One of the major advantages of MVC which has not mentioned here is that MVC provides RESTful urls which enables SEO. When you name your Controllers and Actions wisely, it makes it easier for search engines to find your site if they only take a look at your site Urls. For example you have a car sale website and a page which displays available Lamborghini Veneno cars, instead of having www.MyCarSale.com/product/6548 referring to the page you can choose www.MyCarSale.com/SportCar/Lamborghini-Veneno url for SEO purpose.
Here is a good answer to MVC Advantages and here is an article How to create a SEO friendly Url.
Main advantage of MVC architecture is differentiating the layers of a project in Model,View and Controller for the Re-usability of code, easy to maintain code and maintenance. The best thing is the developer feels good to add some code in between the project maintenance.
Here you can see the some more points on Main Advantages of MVC Architecture.
![mvc architecture][1]
Model–view–controller (MVC) is a software architectural pattern for implementing user interfaces. It divides a given software application into three interconnected parts, so as to separate internal representations of information from the ways that information is presented to or accepted from the user.