Pencil and paper design

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 ...

Re: Pencil and paper design

::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.

Re: Pencil and paper design

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?

Re: Pencil and paper design

::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".

Re: Pencil and paper design

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.

Re: Pencil and paper design

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

Re: Pencil and paper design

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

Re: Pencil and paper design

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

Re: Pencil and paper design

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

Re: Pencil and paper design

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!

Re: Pencil and paper design

Hi João (Oi). As far as I understand your precept is as follows. Map Tables to Collection Classes (Table Root -> RootCollections), Map Records to Domain Classes (Root Records -> Root). What you are doing intrinsically (I Like Programmers :) is that you Collections map to the concept of an Extent of a Class. That is, it "owns" all instances of a class (say Root). You then apply another concept. Becouse you know that the relationship between a Root and a Child is an aggregation, you decide that the child can well be a struct as it will be created and managed by the Root. This is not a good approach without further information! 1) Why do you need the RootCollection? 2) Why do you need any other collection representing the dictomy between Table and Class Extent? 3) Why do you need the RootChildCollection? Anyway I can provide you some short cuts. If you are thinking on using OO to the graburality of a Root or Child and use a relational database, I would advise you to use an O/R Mapper. One can be found for free in "http://ojb-net.sourceforge.net" for you to start learning. Thona also provides one. If you are planning to build one, there is a post somewhere on this forum that as references to whitepapers and stuff targeting the build up of a Persistance Layer/OR Mapping (or just join OJB.NET team (Open Source)). If you don't care less if your OO Objects/Model go to the granularity of Root or Child I would use an approach based on DTO/DAO (Fowler). To cut a long story short, instead of having an Root Class and a RootCollection you have a RootManager or RootService. The UI Layer and BL (The Managers/Service) exchanges information with BL using DTO (Data Transfer Objects). There is no Root Object. In ADO.NET terms A DataSet can be amongst other things a DTO, there are other Classes on ADO.NET that can perform the pattern player of a DTO. Your Managers (Root Manager) need to assure business rules amongst any Root Objects and their associations with Child. There is no Child Manager as you have said a relationship between a Root and a Child is of aggregation. Enjoy, Nuno

Re: Pencil and paper design

Hi Nuno (Oi também) Thanks very much for your answer. I know i have to study much more about UML and OO concepts, before debate them, but i really want to learn. In respect to the names (while this doesn't change anything, could somehow improve the feel) I named ...Collection , maybe is better named ...List. And in ...Detail, maybe ...Info is more correct. The concept is to have an class deriving from CollectionBase and other (an struct) to have his details. The separation was an attempt to have an lightweight (struct) and just readonly members to avoid the instantiation of an say "normal" class with business rules and/or state, when i just need an string representation and an hiden ID. This "List" going to be used in many places for say Select an Item to write his ID has an Foreign key on others tables. Is this wrong? You wrote: "There is no Child Manager as you have said a relationship between a Root and a Child is of aggregation. " Ok, that's fine notice because otherwise i will stay loose. Write now, i have noticed that i could have another approach, say an object that implements an interface with CRUD members, and have the BO that need CRUD behavior deriving from this one. I don't know wich is better, i think it depends from what i need. I'm also trying to model database with ORM (visio), and that's another About O/R mappers, i'm not against, but wright now (i'm an free lancer, so any $$ needs to be well thinking) . After try some free ones (LLBGen, WEO etc.), it's easy to see the great advantadges, as speed development and Most Important error avoid in map, and an unique development method, just to enumerate two of them. But, (i usually use BO to represent any data) there is no easy to have the write maps in a BD table that uses key composition, as in some tables that are composed by foreign keys. I'm not saying that this is an good Sql design, just that sometimes i have to live with that. Maybe i don't have used an good O/R. But this is just an opinion, and from an not very experencied O/R developer. One thing is for shore. I want to learn much as i can about have my next projects begining with modeling. And if i have an forum like this, for shore i will learn quickly. What's your advice: Begin with Data analysis and data flow Begin by UI design Begin by business and process analysis Till now, i begin by some "Users feeling" show them some UI, and construct the data model. But now i have an approach as: Talk with users about the way they interact with the system. Talk again with users with some process analysis, some Use Cases(kind of), and have an blend of all. Thanks again JCasa P.S. Sorry for some "not clear ideias, but thinking fast and write in English it's not my best"

Re: Pencil and paper design

::About O/R mappers, i'm not against, but wright now (i'm an free lancer, so any $$ needs to ::be well thinking) . Hmpf. When I was a freelancer I always got the tools I needed and made it part of my pricing calculation. I mean, every professional out there, doctor, lawer, mechanic, is working with proefessional tools. ::After try some free ones (LLBGen, WEO etc.), it's easy to see the great advantadges, They will actually start to be REALLY obvious once you test O/R mappers. * WEO is a joke, impementaiton wise. It needs a lot of additional work. * LLBGEN is a DAL generator, not an O/R Mapper. ::But, (i usually use BO to represent any data) there is no easy to have the write maps in ::a BD table that uses key composition, as in some tables that are composed by foreign ::keys. Ah, some "not too smart" person making db designs - it is always sad to see designs like this. They blow up the database, kill query and join performance and are extremely hard to maintain :-( You should never: * Use primary keys having more than one column. * Actually have any meaningfull data in the key olumn ::Begin with Data analysis and data flow ::Begin by UI design ::Begin by business and process analysis I normally start with a shot process and business analysis (defining what I have to handle), then make an OOAD cycle to get the key objects, then make the data layer and just start coding a primary prototype of the objects. Then I ggo back and start with details on use cases, state diagrams etc. I NEVER start with the UI for the functional analysis - the UI is always slaved to the process. Not saying that some designer does not start hammering out prototypes to get a feel on how the app should look like. But the object model is always decoupled frrom the UI.

Re: Pencil and paper design

Hi Thona, Thanks for the reply. About i'm an free lancer and must have all tools, ok i agreed, BUT if you have to choose between have an O/R or have say MSDN and an notebook etc. Well, i already choose. Because bad or good i can make my work WITHOUT an O/R, but i can't make my work without VS.net (i know i can do the same with notepad) or without machines and so on. ::LLBGEN it's not an O/R. Sorry, my mistake. Also i post that "Maybe i don't have tried any good O/R". By the way, about one month ago i tried to get your's in the option for not comercial (sorry i don't remember the name option), but never receive the e-mail answer. Please note: I'm not saying that i don't want an O/R, or that an O/R isn't an great tool. Besides that's not the post direction. ::You should never: ::* Use primary keys having more than one column. If you read ALL the post, you saw there: ... I'm not saying that this is an good Sql design, just that sometimes i have to live with that. ... I have to work with some already existing DB designs, some legacy, and say them: This is not a good db design. Do other or even i'will do other, that's just not an option. If i have more work in the future maybe i could just don't accept them, but for now... ::I normally start with a shot process and business analysis... ::But the object model is always decoupled frrom the UI. So you agree that usually the best way is a blend of all with strong emphasis on business analysis and Use cases. ::I normally start with a shot process and business analysis (defining what I have to handle), then make an OOAD cycle to get the key objects, then make the data layer and just start ::coding a primary prototype of the objects. Ok, my problem begins when to decide what's the nouns to eliminate, and after i "could" do that, is try to eliminate duplicate objects and/or merge others in an UML way. Sometimes end in an relationship so complex, that i'm afraid to make an trivial thing in an complex one. I supose the best way with an scennario like this is try to have an new class with the merge members, that could be derived from the others. That's just to say that while i'm just an begginer, but this is just something that i really want to know. Could you send me any direction? Does the experiment is an best option, or do you think i should read more about it? Or both? Thanks JCasa

Re: Pencil and paper design

::Because bad or good i can make my work WITHOUT an O/R, ::but i can't make my work without VS.net (i know i can do the same with notepad) ::or without machines and so on. Hm. How much did you pay for VS.NET? Hint: If you paid more than around 850 USD for the large version including MSDN universal subcription you wasted money and did not ge the correct option for you. ::By the way, about one month ago i tried to get your's in the option for not comercial ::(sorry i don't remember the name option), but never receive the e-mail answer. Hm. COULD have gone lost. Rarely happens, but we had a server issue a month ago where we lost a day's worth of emails. Reapply if you want. I just am sitting here and can give out the key immediatly. ::So you agree that usually the best way is a blend of all ::with strong emphasis on business analysis and Use cases. Yes. The UI is last, though - well, not last. Separate. I have some other guis handling the UI and the planning normally. Someone witha larger focus on usability, nice design etc. ::So you agree that usually the best way is a blend of all with strong emphasis on business analysis and Use cases. ::Sometimes end in an relationship so complex, that i'm afraid to make an trivial thing in an ::complex one. I supose the best way with an scennario like this is try to have an new class ::with the merge members, that could be derived from the others. Most class hierarchies ARE complex. With the right focus you can make them easier, though. BUt compleixty is often power. We work on a SHOP now - the product catalog alone has about 30sth tables, with 40 or 50 objects in there. Most would model this in three tables. But this is not powerfull :-)

Re: Pencil and paper design

this is a gross generalisation: > You should never: > * Use primary keys having more than one column. > * Actually have any meaningfull data in the key olumn i'll take your second statement for now... are you suggesting if you have this table for US states: StateCode char(2) StateName varchar(50) you would actually add a (totally pointless) StateID column for a primary key?

Re: Pencil and paper design

"Write now, i have noticed that i could have another approach, say an object that implements an interface with CRUD members, and have the BO that need CRUD behavior deriving from this one. I don't know wich is better, i think it depends from what i need." I would suggest you to read - ASP.NET Website Programming : Problem - Design - Solution http://www.amazon.com/exec/obidos/tg/detail/-/0764543865/qid=1066138762/sr=8-2/ref=sr_8_2/103-8329706-2479859?v=glance&s=books&n=507846 They follow a similar concept as yours. But it definitly an approach that fits all scenarios. "But, (i usually use BO to represent any data) there is no easy to have the write maps in a BD table that uses key composition, as in some tables that are composed by foreign keys." Yep this can be a problem, specially if working with legacy databases. If you can buy an O/R Mapper then choose one that allow you to deal with this issue. But think for a moment, you only have this problen when you need to work with a legacy database (extending someone else application). But if you develop the solution from scratch then you can have one Column in each table representing the OID (Object Id). Ok, I have pointed out some interesting links about this (www.featuredrivendevelopment.com). There is also a book about the topic: A Practical Guide to Feature-Driven Development by Stephen R Palmer (Author), John M. Felsing (Author) http://www.amazon.com/exec/obidos/ASIN/0130676152/qid%3D1066139652/sr%3D11-1/ref%3Dsr%5F11%5F1/103-8329706-2479859 This is the method that I use for software development as I Like it. But there are others. I begin with Problem Domain Analisis - This can be your "business and process analysis". To this I usually start with some stories (XP). I get this stories from recorded meetings that I have with customers (Yes I use a tape recorder). This also provide some information documents. From this info i define in UML may Overall Domain Model (I use Together Control Central is the best too for this IMO check www.borland.com, it geberated C# code and mantains code in sync with diagrams). This Overall Domain Model is my base line model, it just have business objects (Order, Customer, Fligh, Plane, Ticket, Reservation etc). I do this model with the customer when possible, at least I discuss the model with him (Does this represent correctly a Ticket? What is next after a ticket, a seat reservation in a Flight of Plane? etc etc. This forms my base line OO Model. I usually don't put all properties or methods in this baseline model. Just object associations and notes when there is complex logic going on on associations (But it is a not). This is often called modeling by shape, that is what matter is how objects related with each other rather then their properties. If you take 1 week doing this expect 3 months of development, 2 weeks 6 months and so on. If necessary I build some UI's just to get the fill of the process in an software application. Anyway this is just a prototyped UI. When doing Web Sites (not web applications) sometimes UI is defined up-front or in parallel with Problem Domain Analisis. After this, I have an Overall Domain Model (base line) and I start development. I design my database incrementally as I need from the Overall Domain Model. I can do this becouse I use a O/R Mapper in Java, hopefully soon I'll use one in .NET too :) But there are things to be taken care of first. I can go on decribing my process but is similar to the one described in the book that I've referenced. The book also stated when collaboration analisis should be done. I adapted it to my own taste and according to situation. No in small projects, unless required by the customer I do not use "Use Cases". It is just a waste of time IMHO. In large projects, such as the ones that take 1 year or more and in teams grater then 5 then yes this is an artifact that is usefull in order not to get lost. So what artifacts to I use? FDD - Development Process Stories - Record meetings and sometimes create simple transcripts (summaries) UML - Class Model and Collaboration Model (some time Use Cases but only when it brings some value to the discussion) ORM - Data Modeling Documentation - provided by the customer C# and hopefully soon some O/R Mapper. "The separation was an attempt to have an lightweight (struct) and just readonly members to avoid the instantiation of an say "normal" class with business rules and/or state, when i just need an string representation and an hiden ID. This "List" going to be used in many places for say Select an Item to write his ID has an Foreign key on others tables." Take an Order and its Order Lines (Order [1:N] OrderLine ), are you saying that you will never SELECT All Orders of a given Product?. I'm taking your example as abstract pattern. As for implementation of business rules using OO Paradigm and Business Objects that represent Objects in the Problem Domain read: "Streamlined Object Modeling: Patterns, Rules, and Implementation by Jill Nicola (Author), Mark Mayfield (Author), Mike Abney (Author), Michael Abney" http://www.amazon.com/exec/obidos/tg/detail/-/0130668397/qid=1066141487/sr=8-1/ref=sr_8_1/103-8329706-2479859?v=glance&s=books&n=507846 If you get more interest in modeling. Try modeling with color, facilitating the communication with the customer: "Java Modeling In Color With UML: Enterprise Components and Process by Peter Coad (Author), Eric LeFebvre (Author), Jeff De Luca (Author)" http://www.amazon.com/exec/obidos/tg/detail/-/013011510X/qid=1066141562/sr=1-1/ref=sr_1_1/103-8329706-2479859?v=glance&s=books Enjoy Nuno PS: C# is very similar to Java. If you know C% you will not have any defficulties in reading the Java code presented in the Bools. Enjoy, Nuno

Re: Pencil and paper design

with the id you can reference each row from another table with a INT as foreign key. with state code you would require a varchar... ok, in this example, char(2) does not take much space, but you loose flexibility, as e.g. we in austria would require a char(3) for a state... id's for references are always easy, especially for the web you don't have to escape the values for url_encoding etc.... and you still have the option to declare your stateCode Column as unique... thoean

Re: Pencil and paper design

Well, if you ahve a table of US STates you have other problems :-) YOu are too US centric. But yes, I would add such a table, in this case propably as short. Using things like country codes is one of the rare case this could actually work, as this is an ISO standard (like countrycodes as ISO2), but normally stuff like a social security number ust make a dead stupid primary key (besides being illegal, in case of a SSN).

Re: Pencil and paper design

Hi again, Thona :Hm. How much did you pay for VS.NET? Hint: If you paid more than around 850 USD for the large version including MSDN universal subcription you wasted money and did not ge the correct option for you. I have MSDN licence for cience and high-schools, about 1000 Euros. : Hm. COULD have gone lost. Rarely happens, but we had a server issue a month ago where we lost a day's worth of emails. Reapply if you want. I just am sitting here and can give out the key immediatly. Well, i'm very interested, but not very urgent because of the $$. I have (yesterday) bought an Presario X1010, very expensive but i'm very happy. The screen is 16:9 format. Some strange when saw my apps running, but high quality image. So, i could get the demo and maybe next month we will talk again. Do i take the normal steps? I remember have seen in your last posts that you preparing an last version. Already finished? ::BUt compleixty is often power. We work on a SHOP now - the product catalog alone has about 30sth tables, with 40 or 50 objects in there. Most would model this in three tables. But this is not powerfull :-) That's good news to ear. My afraid to transform something simple say your example 3 in 30 is always one thing that before do it to an finished app that WORK with all requests for the moment... i'm shore you know what i mean. But then, usually i could resist to do something when revising old code. Do you think Visio is enough to start with?