|
Hi,
At work I have created a homebrew framework ColdBlood with various object oriented design features; one is persistency.
In the specification (interface) of each object type we differ between properties, references, child and children. We do this using different attributes (in C#). A property can have the optional flag Persistent enabled, which means this property is serializable.
All the specification attributes are compiled into some info classes for fast lookup e.g. by the serializer/deserializer.
This design means a complete separation of persistency specification and serializer/deserializer implementation.
Currently, we use a serializer/deserializer implementation with multiple ToBytes and FromBytes methods. The resulting byte data can be transfered to/from files or sockets.
Kind Regards,
Keld Ølykke
|
|
|
|
|
Is this the forum for asking questions about USB ?
I'm implementing the USB stuff in firmware, and frequently the rules (particularly the protocol) don't make sense from the documents I'm reading.
|
|
|
|
|
> "Is this the forum for asking questions about USB ?"
No. Try Hardware & Devices
"It's true that hard work never killed anyone. But I figure, why take the chance." - Ronald Reagan
That's what machines are for.
Got a problem?
Sleep on it.
|
|
|
|
|
Thanks, headed over there now
|
|
|
|
|
pls tell me some good book of arm cortex m3
also i want to work using embedded c so if someone can tell me some good book that will corelate the two
|
|
|
|
|
|
Hello,
I have a begginers design issue.
I'm building an layered application(Presentation layer, Business logic layer and Data base layer).
I have three entities in my application:customer,staff member and vendor that all of them deriving from person.
The user can add new customer,staff member or vendor to the data base(using UI).
My question is which layer is responsible for the next tasks:
1.Validating user data
2.Saving customer,staff member,vendor in to the DB.
3.Retrieving customer,staff member,vendor from the DB.
4.Perform other DB related manipulation with customer,staff member,vendor.
5.Which classes i need to define to perform the above tasks.
I'm new in to object oriented programming so thru the current question i am trying to understand the concept.
Thanks
|
|
|
|
|
columbos14927 wrote: I have three entities in my application:customer,staff member and vendor that all of them deriving from person.
Vendors are almost never "people". They might have sales people representing them but those can change.
Also customers can be companies and thus not "people" either.
columbos14927 wrote: My question is which layer is responsible for the next tasks:
Business layer.
|
|
|
|
|
columbos14927 wrote: 1.Validating user data
a) client side input validation should be in presentation layer.
b) Server side input validation should also be in presentation layer.
c) Business rule validations should be in business logic layer.
columbos14927 wrote: 2.Saving customer,staff member,vendor in to the DB.
Actual data base CRUD operations will be in Data access layer but on successful validation the operation should be done in Business logic layer.
columbos14927 wrote:
3.Retrieving customer,staff member,vendor from the DB.
4.Perform other DB related manipulation with customer,staff member,vendor.
Again, the db layer should contain the data access logic and db entities. The actions should be triggered from business logic layer.
Perhaps these article could be a little useful for you:
Creating ASP.NET Applications with N-Tier Architecture[^]
YaBlogEngine - A Tiny Blog Engine written in ASP.NET/C#[^]
Twenty years from now you will be more disappointed by the things that you didn't do than by the ones you did do. So throw off the bowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore, Dream. Discover.
|
|
|
|
|
What are peoples' experiences with software design like?
I'm a firm advocate of the 6 P's: Proper Planning Prevents Piss Poor Performance, which to me means having a clear idea of what you want to achieve, and the necessary oversight to be able to make informed decisions.
For this purpose I find UML incredibly useful. Component or package diagrams help me determine my solution structure, decoupling of components, separation of concerns, reusability etc and completely prevent circular references.
Before I touch VS to set the solution up I make sure I've got this down, even if it's only a couple of projects and a test project. It's like I documented it before I even started.
I'm a bit baffled by some of my colleagues who expend a lot of unnecessary time and effort trying to keep their 100+ project solution in some sort of check without some sort of visualised overview. Just trying to add a single interface requires a three hour discussion involving everyone (6 developers, 18 person-hours, almost half a person-week) from two teams whereupon the only conclusion that's ever been reached in one of these productivity abyss meetings is "we need to add a new assembly" because their lack of oversight has made their solution so tightly coupled and interwoven that it's the only way short of taking everything apart and putting it back together again.
In my experience, when groups of developers have to resort to mentally storing lots of abstract information in the absence of a visualised overview, nobody can make informed architectural decisions and the solution grows organically and totally unchecked until the dependencies either get so complex that nobody knows what to do, or you run into a circular reference and people start throwing in arbitrary assemblies as a hacky workaround.
I've taken to going into discussions with the other group armed with a package diagram of their solution so I can tell them where to put what in their work. If I don't do this, each meeting descends into chaos with various people trying to compile lists or matrices of references which is exactly what the package diagram is representing. Afterwards you hear murmurs of "an overview diagram like that wouldn't be a bad thing", but nothing gets done about it unless I do it for them.
What do other people think?
How can I motivate my superiors to take software architecture seriously and value the advantages a bit of forethought will bring?
|
|
|
|
|
There's the problem of writer's block when using diagramming tools. The visual noise of icons/widgets in software tools I find very distracting. (such as Microsoft Visio)
I find it easier to think away from a computer completely, and use pen and A3 artist pad, and use my Boogie Board to write down changes/new approach when I'm not directly working on a problem.
I get stressed out staring at computer screens for hours and that's my reason for getting away from them.
"It's true that hard work never killed anyone. But I figure, why take the chance." - Ronald Reagan
That's what machines are for.
Got a problem?
Sleep on it.
|
|
|
|
|
jim lahey wrote: because their lack of oversight has made their solution so tightly coupled and
interwoven that it's
Not sure that has much to to with the rest of this. One can of course use UML and formal designs and create exactly the same sort of problem.
And from my own perspective I would like to think that my code doesn't do that, and I don't credit design for that but rather experience.
jim lahey wrote: What do other people think?
UML by itself isn't sufficient. I use UML and encapsulate it in a design document.
But I don't do it for others since that is often a futile effort.
jim lahey wrote: How can I motivate my superiors to take software architecture seriously and
value the advantages a bit of forethought will bring?
There are numerous studies that show significant benifits from formal process control. Reduced delivery times, better scheduling, better resource utilization, reduced bugs, reduced overall costs, reduced maintenance costs are some I believe I remember.
There are however countless stories about organizations that fail to implement process control correctly. And many ways to blame the failure (usually on the process methodology while ingoring the role developers play.)
Best incentives that I can remember, again from the studies (IEEE and ACM) were
1. A senior VP or higher must consider process control a primary goal.
2. Employee reviews must have a significant percentage of the review devoted to how well the developer and mid-level managers participated in the process control processes. It certainly helps if bonuses/raises are based on the review and thus correct participation in process control.
|
|
|
|
|
I don't think the problem you're experiencing is unique to software. In many walks of life you will find people who 'just want to get on with it' or haven't got 'time to waste' designing and planning. Or just don't know any other way yet.
When learning to program I reached a point, about 4:00 in the morning if I remember correctly, with reams of code printout spread across the room trying to track down mis-behaving pointers when I became convinced there had to be a better way. I found eventually it the form of a book on OOA/OOD in a university book shop, and later in the form of UML, Interface design etc. But I already had the motivation to find a better way.
I do think that your comment about developers 'mentally storing lots of abstract information' is a common problem. I know how developers 'want to program' - as I, and probably most people using CodeProject, once did or still do. Once typing or coding has started, it becomes a mental challenge, probably for the same reason as do crosswords and so on. Being in a position to promote the use of Components, Interfaces, Decoupling and design in general, aided by UML as the visualisation medium, I found some 'enlightened' developers took to analysis and design well, seeing - or showing each other - how it could aid and clarify the mental juggling act of information - and how it could contributed to making things work. Though I also came across quite a few who "didn't do UML" or professed not to understand, or simply drew a diagram then got on with it just as before.
Everyone concerned with what you're doing has their own perspective: from developers to managers to clients. I know it's software technicalities under discussion but you need to put across your points in a way that the people your addressing can understand - and see advantage in; and they might not be 'software people'. So you might need one set of arguments to convince your managers and another to convince fellow developers. Demonstrations can help a lot. The project management 'iron triangle' of Cost; Time; and Quality, and also Risks: 'what if ...?' are good starting points to measure and convey the benefits to more senior people. In fact UML can be pretty confusing, so it might be best not to use to use UML as the medium to try and convince of the need for design using UML.
A lot of discussions about reasoning for the use of software design tend to use as a starting point the metaphor of a construction architect: producing a simple diagram to get the 'feel' of what's needed, then more detailed plans to put to the owner and planning officials. Then other plans for the builders, electricians etc. This illustrates that differing perspectives exist requiring differing plans - but this is also then used as a jumping off point for putting a question of the form: You wouldn't consider putting people to work on a building (or some mechanical equipment) without an accepted design and plans, so why would you consider building (or letting be built), something complex like software without an equivalent design in place.
'Lessons learned' i.e. examples of where design and UML would have helped, or did help, is also an accepted format for putting across arguments such as you have.
There are a lot of 'enlightened' software designers, architects and coders out there.
|
|
|
|
|
Hi All
interesting thread, especially as I'm of the building architecture type designer and a tutor in that field also.
I find it interesting and fitting that architecture is use in software design.
In our field we establish constraints, analyse the brief, create bubble diagrams (like flow charts) create a site analysis (considering the "environment" and "context") draw some sketch designs (remembering the type of drawing has to be suitable for the viewer, perhaps the client (maybe little knowledge of construction), the client is shown drawings that will describe to them how they'll experience the building and its spaces. Maybe drawings are done for other consultants (mostly interested in there disciplines) and they can handle much more detail and are less interested in the experience. And all the way through are trying to do all this within the budget.
I hope you appreciate the analogy
Nigel
|
|
|
|
|
As a building architect, or as a software architect, you might be interested in John Zachman's 1987 article on the need for IT systems architecture which he presents based on an analogy with building architecture and plans. In 1987 he starts with a bubble diagram as do you 25 years later which perhaps shows the maturity of the building architecture design process compared to IT and software systems design processes. Perhaps due to the rapidly changing IT landscape and the options open to IT/software design, such IT maturity is yet to be established, or maybe the analogy doesn't hold there as IT changes so rapidly.
http://www.zachmaninternational.com/index.php/ea-articles/28-1987-ibm-systems-journal-a-framework-for-information-systems-architecture[^]
|
|
|
|
|
Jonathan Davies wrote: Perhaps due to the rapidly changing IT landscape and the options open to
IT/software design, such IT maturity is yet to be established, or maybe the
analogy doesn't hold there as IT changes so rapidly.
Not to mention that the vast majority of projects in IT are substantially different than every other IT project.
If 90% of architects spent all of their time developing building that were substantially different than all others and had a lead time that is typically less than a year then it might be similar.
|
|
|
|
|
I do like your analogy.
We tend to use the Software Design and Software Architecture loosely as equivalent terms. However, there are two different things.
In a nutshell, Software Architecture captures nonfunctional requirements( environment and system constraints, technologies, platform,...), analyses high level structure of the software components. The goal is a Software Architecture Design Document which is very important in stakeholders' early decision.
In contrast, Software Design or Software Implementation Design to be clear, elicits functional requirements. It is about detail implementation of divers software components.
Incidentally, Software Architecture and Software Design don't use the same techniques or methodology to meet their respective goals( they don't have the same goals!!!). The former uses 5 Architectural Views for example produce the Software Architecture Document, but the latter deals with class diagrams, sequence diagrams, use cases, state diagrams, etc... to produce Software code.
This is just a glance about a large topic.
modified 28-Apr-13 14:41pm.
|
|
|
|
|
Anything more than a simple App I will design properly.
Start with a requirement outline and build the candidate classes from there. Then add in use cases to see what is needed or missing.
I use UMLet[^] for modelling and I try to at least model the main classes and activities.
Reality is an illusion caused by a lack of alcohol
|
|
|
|
|
Its a nice discussion. I would like to add some of my approaches to convince the management about a Software product Architecture:
1. At first I directly talk with my managers and try explain them about the importance of proper Architecture.
2. I prepare a POC and then have a meeting again with them.
3. I even include Tech Leads & some Senior Developers.
4. I circulate some supporting articles/blogs to them.
Be a good professional who shares programming secrets with others.
|
|
|
|
|
I really have fallen in love with the DDD concept. In short this is how we always work out a project.
All you need in the beginning is a whiteboard and a marker.
1. Define the domains within the scope of your project
2. Define the components within each domain.
3. VERY IMPORTANT: Give the domains and components GOOD names.
4. AGREE on the CONTRACTS of each component
5. Document your Diagram and Contracts.
6. Split the teams up each dealing with their component(s) and let them create UML diagrams.
7. Let each ULM diagram be coded out by a team that did not create the diagram.
|
|
|
|
|
I am trying to make distributed application in RMI/CORBA like ebay : allow individuals to submit classified ads to sell items with an auction system. At the closing date of the auction, the buyers who bid the last (if it exists) has the privilege of being able to acquire the object.A user can at any time be buyer or seller. Information of "user" necessary for the rest are mainly: name, password, bank details.
As want to operate::
1: Get a list of items currently for sale (list or search by keyword possibly). Obtained including a description, a current price, a date (or time remaining) closing of the sale.
When an item is worth :
1: get a minimum of information about the seller
2: the bid there must have authenticated.
Can I get help and little explanation about the architecture?
Thanks
modified 19-Mar-13 20:12pm.
|
|
|
|
|
docomo1 wrote: Can I get help with some code and explanation
Sure.... post some code that you are having trouble with and I am sure that someone can explain it.
If you are wanting someone to write this code for you and then explain it to you, I think you have come to the wrong place.
|
|
|
|
|
haahahaa....ofcourse I m not excepting that...!!!
|
|
|
|
|
docomo1 wrote: ofcourse I m not excepting that
And how do we know that? You did not post any code or ask a question so what is left when all you did was ask for someone to write some code for you?
|
|
|
|
|
Well I am editing it....why u misinterpreted that...if u also know that this is not the place to give the code ...n I already admitted ....but u stick on that point rather than the main subject...strange..!!!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
