Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

UML for the Software Developer, Part 1: Building Classes : Page 3

Whatever language you code in, however you feel about documentation, and whichever process you ascribe to—you will need to model. Whether those models are in a formal charter, reference document, part of a diagram, or on the back of a napkin, you as a software developer will end up using models or modeling yourself.


advertisement
Iteration 2: The Collection Type
Figure 2. Enhanced Brokerage Class: In this second iteration of the Brokerage class, the char[] type has been replaced by the String type and the char* has been replaced by the Collection type.
In Figure 2 the char[] was replaced by the String type and the char* was replaced by the Collection type. In the .NET languages, these types are part of the native language—they are part of Systems.Collections. In the examples, ArrayList was used instead of the more abstract CollectionBase.

So in practice, you declare these types in UML and do not display them with the class diagram itself. If you look closely, you'll see I added the collections to the Brokers, Clients, and Securities attributes. This makes sense from a coding standpoint as well, but why did I leave the [1..*] and [0..*] qualifiers next to the collection? This is our first example of how modeling differs from coding. I used the qualifiers to specifically declare that the Brokers and Securities collections must be initialized with at least one element.

The Clients don't need to be initialized. Why do I do this? In developing this system you need at least one broker to do anything with the system. The broker would need at least one security to buy or sell, but it isn't until he buys or sells the security that he then needs to give it to the client. In the current class you are just adding, deleting, and listing the brokers, clients, and securities, but in a real system you would want brokers to buy and sell securities for their clients. One could argue that the SEC requires that the broker have a client before he buys or sells a security, but from a system standpoint it doesn't matter if the client exists before or after buying or selling a security.

It wouldn't be difficult to implement this class in C#. If the UML tool that you are using generates code, then it might generate something like this:

using System; using System.Collections; public class Brokerage { // Generated Code was refactored for readability. The “Using” statements were // added by hand. Return statements are also added in most of the modeling tools but // removed here. private ArrayList Brokers; private ArrayList Clients; private ArrayList Securities; public Brokerage() { InitializeComponent(); } public void addBroker(String Name){ } public void deleteBroker(String Name) {} public ArrayList listBrokers() {} public void addClient(String Name) {}

The only thing that needs to be done from this point is to add some implementations to the code and you have a class that you can hook up to a GUI and voilà!



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date