I've given up waiting for
this excellent article to extend into the promised series. I am about to code my first true application. I have researched my app, written its Statement of Purpose, written its User Scenarios, planned its UI, chosen the Patterns I intend to implement, structured
its data and its passage through my layers. Basically, I'm confident I have finished the pencil and paper stage. However, I'm at a bit of a loss as to how to correctly and reliably move my application from paper to code. I'm okay with the paper design ...
and I'm okay with writing code ... but how do I move from the former to the latter? How do I map what I have on paper to corresponding classes and components? (I do not wish to use software like Visio or make use of UML for my first app. I want to understand
why I am taking each step, not just connect-the-dots. And please, I understand that this is not what Visio or UML are about. I simply don't want to use them for the same reason that newbies shouldn't use drag-and-drop design for their first app.) I cannot
find any articles about this "rolling up the sleeves and getting my hands dirty" process. Ideally the article will presume the development environment to be .NET ... but it doesn't have to be. (But it should involve an OOP language, not a procedural one.)
Does anyone have any recommended online articles? (I don't want to buy yet another heavy and expensive book.) Thank you to anyone who can offer guidance ...
::I do not wish to use software like Visio or make use of UML for my first app. I want to ::understand why I am taking each step, not just connect-the-dots. This is your error. UML and Visio are not "connect the dots". UML (and visio as a UML tool) is nothing
more than a standard diagram way to describe your design. You say you have a design - how have you formulated it on paper? Without UML you had to use another set of diagrams. UML is a tool to express your thoughts, not "connect the dots". It does not teach
you hot wo think. It merely catches your ideas in a standard way most developers can read. ::I have researched my app, written its Statement of Purpose, written its User Scenarios, ::planned its UI, chosen the Patterns I intend to implement, Ah, and what "language"
have you dont so in? UML is nothing more than standards so that I could understand your document. Like "User Scenarios". These are called "Use Cases", and I bet I would not easily understand what you have now unless you have used UML.
Thanks for your response. After writing my post, I regretting making the "connect the dots" analogy ... as I realised it would draw criticism rather than assistance. In
the MSDN article to which I initially referred, no mention has been made of the
necessity of UML. Whether I use UML or my own diagrams, and whether I say "User Scenarios" or "Use Cases", is unimportant. Even if I fire up Visio and "capture" my ideas in a standard way, I still arrive at the same stumbling point... How do I move from
a set of diagrams to a set of components and classes? Anyone know of any online articles about this process?
::Whether I use UML or my own diagrams, and whether I say "User Scenarios" or "Use ::Cases", is unimportant. Even if I fire up Visio and "capture" my ideas in a standard way, I ::still arrive at the same stumbling point... Absolutly. The question is whether
other people understand you. ::How do I move from a set of diagrams to a set of components and classes? Again the wrong question - or, formulatedin the wrong way. Because you normally make this step WITHIN the diagrams. Component and Class diagrams are apart
of the UML standard - I prefer to line out the most important aspects of my systems normally in diagrams, although these sometimes appear after the initial prototype. Now, for the way to find classes there are various ways: * Common sense - once you ahve experience.
Obviously off right now. * Standard OOAD techniques. Try reading up on CRC cards for an easy way - they are not UML, and I urge you to move the results into a class diagram (much more readable than a stckof cards9, ut they make a relatively great deisgn tool.
Google has some good links to "CRC Card".
Humm, this is an interesting question as it leads to development methodology. Without knowing better about what kind of artifacts you have used to establish your design here it goes. So I suppose that you already have an Object Model ot a Database Model to
work with (base line model). By know you probably have a set of features to develop. I would devide them in three layers UI Features (as you have done your UI design) Business Features Architectural Features I would focus first on the Business Features. That
is features that encompass what actually your app is suppose to automate. Within this, I would classify those feature in the following manner. Subject Area Business Activity Feature An exqample of this could be [Order Management] [Selling a Product] [add Product
to Shopping Cart] [calculate the Total of an Order] [place Order in OrderList] [Product Catalogue Management] etc [Forum Managment] etc For each Business Activity enumerated I would put a completion date. That is Business Activity X will be eady at 8/12. After
you have this you can start build your application by Feature. To this pick a set of Features to be developed in the next 15 days. The features you pick will form your WorkPackage for the next days (focus focus). After you have finished choose another set
of features and proceed. For more information about this, www.featuredrivendevelopment.com Hope it helps, Nuno PS: There are other strategies but this is the simplest to understand I believe.
One more thing, If you don't have yet a Object Model or a Database Model then you have not yeat performed you Analisis or Design. This are the first things to do before thinking on wich patterns to use to code. But I guess you already have defined the base
line. Nuno
You don't need UML particurarly. But definitly you need a language to state what kind of Objects you are dealing with on you problem domain, right?. UML is the best you can get IMHO. Nuno
Within all my replies there is a doupt that I have that basically steams from this statement. "... but how do I move from the former to the latter? How do I map what I have on paper to corresponding classes and components?" Do you already have a Domain Model.
That is a Database Model and/or Object Model? If you do have a baseline Object Model, that is great :) This model actually solves your problem your initial problem (What classes and components do I need). If you only have a Data Model you need another step,
"How to map the Data Model to Domain Objects in conceptual terms?". Now if you do have your Object Model, the next thing is "How to map business rules to your Objects?" This appart from association/relation multiplicity. I suggest you to have a look at www.streamlinedmodeling.com
for this. The next thing, is How to map all this into an architecture? Well, you are in the right forum for that :) But you need to have "first" the things that I've mentioned established in your mindset. I appreciate that you are trying to understand what
actually you are doing from project incept to delivery, instead of leaping through concepts (like the article does). You have choosen the hardest path but the most rewarding in a learning process. Enjoy, Nuno
Hi all, I have an Database Model not finished because i hope improve it after trying to model some user requirements in Visio. Assuming one table named Root with an one-to-many to an table named Child. By now i try to model this user requirements in a visio
static model: Users can list Root and select an member: class named RootCollection and an struct named RootDetail with appropriated attributes. Composition: RootCollection-> 1 : 0..* Rootdetail Users can list Child and select an member: class named ChildCollection
and an struct named ChildDetail with appropriated attributes. Composition: ChildCollection-> 1 : 0..* Childdetail users can make CRUD actions to Root or to any dependent Child class named Root, class named RootChildCollection and class named RootChild Composition:
Root-> 1 : 1 RootChildCollection-> 1 : 0..* RootChild Now, (suposing that the previous is well model) what if i need to have an table named GrandChild that is many-to-one to Child? Does it mean to step down with the same logic? Like: class named ChildGrandChildCollection
and class named ChildGrandChild Composition: Child-> 1 : 1 ChildGrandChildCollection-> 1 : 0..* ChildGrandChild Could you comment? P.S. If my mode of presenting an Composition or any other thing isn't wright, I appreciate some directions. Thanks in advance
JCasa
Thanks Thona. Even though this current development is for my eyes only, I recognise the value of what you've been saying about UML. So, I've downloaded some software so that I can learn how this works. The formality of CRC cards is also interesting, particularly
as I had already made my own (less formal) cards to document my classes. Thanks, nbplopes. Currently, I haven't the faintest idea what is a "base line". But, I'm not asking for an explanation, as it's simply been added to my list of things to research. However,
judging by your description then, no, I don't yet have a base line model. I have outlined the structure of my data (which is XML), and I'm comfortable with it so far. I also have outlined the UI of my app, and I'm comfortable with it so far. As you've intimated,
it is the middle Business/Logic Layer that is my stumbling point. So, as you've suggested, my first question should be, "How to map the Data Model to Domain Objects in conceptual terms?" Then, you suggest my second question should be, "How to map business
rules to my Objects?" Then, "How to map all this into an architecture?" These are excellent questions, and I appreciate the links to help answer these questions, thanks nbplopes. You mention Feature Driven Development. I am currently looking into this. So
far, I really like what I am reading. I have previously looked into XP, but this didn't work with me (a single developer doing this stuff at night). You're also right that I have chosen a slow, difficult path for my first app. But, as you say, I believe it
will be the most rewarding. It's simply hard for a newbie to know how to start. However, with your help and the help of Thona, I now have some paths to follow. Thanks, guys!
SomeNewKid
All-Star
45894 Points
8027 Posts
Pencil and paper design
Oct 12, 2003 09:15 PM|LINK
thona
Member
20 Points
2923 Posts
Re: Pencil and paper design
Oct 12, 2003 10:12 PM|LINK
SomeNewKid
All-Star
45894 Points
8027 Posts
Re: Pencil and paper design
Oct 13, 2003 04:49 AM|LINK
thona
Member
20 Points
2923 Posts
Re: Pencil and paper design
Oct 13, 2003 05:59 AM|LINK
nbplopes
Participant
1745 Points
349 Posts
Re: Pencil and paper design
Oct 13, 2003 09:14 AM|LINK
nbplopes
Participant
1745 Points
349 Posts
Re: Pencil and paper design
Oct 13, 2003 09:18 AM|LINK
nbplopes
Participant
1745 Points
349 Posts
Re: Pencil and paper design
Oct 13, 2003 09:20 AM|LINK
nbplopes
Participant
1745 Points
349 Posts
Re: Pencil and paper design
Oct 13, 2003 10:57 AM|LINK
João Ca...
Member
500 Points
100 Posts
Re: Pencil and paper design
Oct 13, 2003 09:30 PM|LINK
SomeNewKid
All-Star
45894 Points
8027 Posts
Re: Pencil and paper design
Oct 14, 2003 03:05 AM|LINK