I'm an university student and I'm trying to do a class diagramm for a very simple client-server game.
The game consist of a online rouge-like when 2 player explore a dungeon. I'm having trouble to identify an easy class diagramm. Should I show in the class diagramm the server class and the client class? What other classes should I add?
Here is what I’ve done so far:
It is recommended to keep class diagrams small and focused on a given topic. This is true for simple games, as it is for complex systems. This leads to have several diagrams that are easy to read rather than one big and extremely complex diagram with all possible classes of your system. It would therefore seem better to keep client and server classes separate in different diagrams.
In the special case of a client-server system, the client and the server might moreover have different designs targetting different technologies. This is one reason more to keep them separate, unless you intend to reuse the same design on both sides, for example if you intend to have a common code base with a rich client.
However, it could be very helpful to you, to use a component diagram, at a higher level than individual classes. Component diagrams allow to focus on the interfaces between the parts of your system and will allow to explain the big picture (e.g. that there is a client and a server and how they are interfaced) before diving into the details.
Related
I need to develop a system for a library system from Java & Netbeans. I am wondering do I have to include classes made from Netbeans for user interfaces in the class diagram. In addition to that suppose we have a class "Librarian". I assume that I can create two classes one for UI and one that including details in the class diagram and use it in the UI class. Or I can implement, what class diagram says directly in the UI class for "Librarian". Please tell me which is the correct way that software engineers are supposed do.
Whether or not to show something in a class diagram depends on the intention of the editor and what he wants to show to his audience. Often it's a good idea to create overview diagrams where you omit details. The overview is then accompanied by a couple of detail diagrams which are logically oriented at sub-domains which in turn help to understand the systems as a whole.
Also it's not uncommon to just leave out "obvious" things. If you work with known scaffolds in certain domains you must not describe that again and agin but just can assume that it's known. In your case that would be the GUI part which will be known implicitly. You might consider to create a sketch of the scaffold somewhere in a more general class diagram. This could be helpful for people coming from other worlds (and not knowing NetBeans like me).
Beware of drawing wall-papers that contain each and every detail in a single class diagram. Looks impressive but is absolutely useless (an anti-pattern if you like to call it that way).
I have a project and I'm required to produce the class and sequence diagram. It is a procurement website. My only problem is that I don't know how to associate the web pages (user interfaces) to these diagrams. If they are not needed what is the right way for me to include it in the diagrams because from a book I read there are "UserInterface" classes, so another question, what should be inside of these UI classes.Can someone give me an example. Thanks!
There are several levels of abstraction for UI modelling.
Use cases and state machines. These diagrams are made in human terms.
Planning on the server/page/frame level. Here UML deployment and component diagrams are useful.
Planning of the content of UI, defining elements and functonalities and connections between them WITHOUT choosing the concrete components. No standard for this, extremely important, stage. Use diagrams that you like. Class ones are usable, but in not standard reading.
Planning of the content of screen elements WITH choice of the UI components (frames, buttons and so on) and connecting functionalities to them. On this level you can use class and sequence diagrams.
Drawings of the planned screenshots. For this level there are no UML diagrams. And a common standard doesn't exist.
These levels require MANY diagrams. The lower the level, the more diagrams it needs. Putting user interfacES into one class diagram is possible for a minuscule project, but you can't say it SHOULD be done so.
In your class diagram you will normally describe/design the (data) model part of your application, while the user interface (UI) corresponds to the view part within a model-view-controller (MVC) architecture. As a UI cannot be designed with a class diagram, I cannot see any meaning for a "UserInterface" class.
However, there is a new modeling language for modeling user interfaces: the Interaction Flow Modeling Language (IFML), which has been adopted as a standard by the OMG in March 2013. If you are serious about UI modeling, then you should use that language.
Classes of UI can be modeled as ordinary UML classes. You can create stereotype "webpage" if you want of course. If it is needed to define internal structure of UI class use composition. In sequence diagram you can define interaction between instances of UI classes in common way.
Example:
I want to question and/or perhaps challenge the school of thought on UML behavioral diagrams.
Firstly, I want to ask, what comes first: Use Case or Activity?
I was taught that Use Case diagrams come first and then for each Use Case, you have one or more Activity diagrams to represent successful and alternate flows. From the Activity diagrams, you can identify nouns to establish classes.
I have, however, read other articles which say you create an Activity diagram for the end to end process and then from that, you can identify Use Cases.
I can see both scenarios working, and am confused, as to me it seems a case of hierarchy. For example, say I have a high level business process which is 'Grading Student Results'. If I map it as an Activity diagram, within which I would see swim-lanes. I would be able to pick out Use Cases, such as 'Determine Grade Boundaries,' 'Submit Results,' 'Convert Result to Grade,' and so on.
You could argue they are the same thing, i.e. both diagrams would meet this process modeling need. I then want to model the next level, for example, how you 'Submit Results.'
Can someone advise on the best practice: whether a Use Case diagram comes before or after an Activity diagram?
First:
There is no competition between any of the UML diagrams to be the "first
one". Sometimes it is better to work on some diagrams simultaneously and iteratively.
Second:
Each diagram can be used in different contexts and for different purposes.
Use Case Diagram vs. Activity Diagram
"Use Cases" are scenarios which show how the user will use the system to achieve their goals.
So:
Instead of showing this "scenario" with written use cases, you
can visualize its' steps with an activity diagram.
But in order to find use cases, you should discover the system requirements to some degree, (e.g. the scope, broad feature set, priority, cost, etc.).
In some business domains, such as for an automation project, in order to discover requirements/use cases, you may have to investigate current business flow. Sometimes this business flow can be complex, so you may want to investigate it with an activity diagram.
So:
An activity diagram can be used to investigate a business process to
understand and discover the flow, to better discover requirements.
So:
An Activity Diagram can be used at different levels of software
development stages for different purposes.
Just like other diagrams, you can use the Activity Diagram at any time, anywhere, as soon as it can help you to ask the right question, to understand and explore any issue related to your purpose.
Here is a summary purpose of Activity Diagrams:
The purpose of the activity diagram is to model the procedural flow of
actions that are part of a larger activity. In projects in which use
cases are present, activity diagrams can model a specific use case at
a more detailed level. However, activity diagrams can be used
independently of use cases for modeling a business-level function,
such as buying a concert ticket or registering for a college class.
Activity diagrams can also be used to model system-level functions,
such as how a ticket reservation data-mart populates a corporate
sales system's data warehouse.
UML Basics : The activity diagram by by Donald Bell
To get a quick grasp of which diagrams can be used for which purposes, I advise you to check out Scott W. Ambler's mini book: The Elements of UML(TM) 2.0 Style
Activity diagram is one of the those with widest abstraction range in UML. An activity can be used for anything between a business process (very abstract, comparing with software system) and a single method algorithm (code-level, practically blue-print, meaning kind of abstraction ground level).
Use Cases on the other side are in practice very limited in their abstraction. They show the interaction between a user and the system and would be somewhere in the middle of the abstraction scale. Not as abstract as a business process, and definitelly a lot more abstract than the implementation diagram.
Software projects tend to start working on a very abstract level (business goal for example) and finish with the abstracion 0 (implemented system). During the project analysts, architects and developers work together to gradually lower this abstraction producing always less abstract artifacts/models - business processes, use cases, architecture, design, code.
After this introduction it is not hard to answer your question - any of those can be used first and that depends on type of your project and its size. SOme examples:
A large project of development an ERP system. It is almost certain that in this kind of project the first thing to model is the business process. A long before even thinking of its functionality, the team must understand the business background. The best UML diagram for this is naturally the activity diagram. Some time after, when the process is clear and the high-level reqs known, the use case modelling can start.
A middle sized of relativelly small project, with no complex processes in background (for example a mobile app development) can start directly with use cases, identifying the users and their features. Later on, these can be further refined using activities.
A very small development of some interface, driver of communication gateway, highely technical, where even the user interaction is minimal, the modelling can start with the activities again, showing the concrete algorithm too be implemented. USe cases can be completelly skipped.
As a summary I would conclude that there are no unbreakable rules of this kind in software development. Each project is unique, each development methodology is unique, even each development team is special and unique. To think about "which diagram" to do first is straight and simply WRONG! Think about what kind of analysis or specification you need in a given moment - what is easiest and most usefull to be modelled. When this is clear - there are 13 UML diagrams to pick up from in order to optimally fulfill the aim.
Choice of UML diagram is the "HOW". More important than that is more often than not - the the "WHAT".
Use case diagram is for showing the functionalities and Activity diagram is for showing operations(1 functionality can have many operations).
eg. Use case diag. is Moher (can have many childrens) and
Activity diag. is like describing the child of Mother i.e. Use Case diag.
I've noticed in pretty much every company I've worked that they have a common library that is generally shared across a number of projects. More often than not this has been a single companyx-commons project that ends up as a dumping ground for common programs including:
Command Line Parsers
File Utilities
Framework Helpers
etc...
Some of these are well thought out and some duplicate functionality found in Apache commons-lang, commons-io etc..
What are the things you have in your common library and more importantly how do you structure the common libraries to make them easy to improve and incorporate across other projects?
In my experience, the single biggest factor in the success of a common library is user buy-in; users in this case being other developers; and culture of your workplace/team(s) will be a big factor.
Separate libraries (projects/assemblies if you're in .Net) for different application tiers is essential (e.g: there's obviously no point putting UI and data access code together).
Keep things as simple as possible; what you don't put in a common library is often at least as important as what you do. Users of the library won't want to have to think, so usage needs to be super easy.
The golden rule we stuck to was keeping individual functions focused on a single task - do one thing and do it well (or very very well); don't try and provide something that tries to take every possibility into account, the more reusable you think you're making it - the less likely it is to be used. Code Complete (the book) has some excellent content on common libraries.
A good approach to setting/improving a library up is to do regular code reviews and retrospectives; find good candidates that you've already come up with and consider re-factoring them into a library for future projects; a good candidate will be something that more than one developer has had to do on more that one project (for example).
Set-up some sort of simple and clear governance of the libraries - someone who can 'own' a specific library and ensure it's overal quality (such as a senior dev or team lead).
I have so far written most of the common libraries we use at our office.
We have certain button classes that are just slightly more useful to us than the standard buttons
A database management class that does some internal caching and can connect to ODBC, OLEDB, SQL, and Access databases without even the flip of a parameter
Some grid and list controls that are multi threaded so we can add large amounts of data to them without the program slowing and without having to write all the multithreading code every time there is a performance issue with a list box/combo box.
These classes make it easier for all of us to work on each other's code and know how exactly they work since we all use the exact same interfaces throughout our products.
As far as organization goes, all of the DLL's are stored along with their source code on a shared development drive in the office that we all have access to. (We're a pretty small shop)
We split our libraries by function.
Commmon.Ui.dll has base classes for ui elements.
Common.Data.Dll is sort of a wrapper around Enterprise library Data access classes.
Common.Business is a dumping ground for other common classes that don't fit into one of those.
We create other specialized dlls as needs arise.
What is CSLA Framework and Its use ?
My Opinions From My Experience w/ a 1.7M LOC code base:
CSLA is intended for a distributed application/database environment. This is why the basic business object is and does everything, for example it's own data persistence. An object (and everything remotely associated w/ its state) is intended to be serialized, sent to a different application and/or data server and work.
If the above is not a problem you need to solve, CSLA is overkill, big time. Our development team regrets having committed to CSLA.
Juggling all the CSLA balls in a complex Windowed UI is tough. We have multi-tabbed screens (which may in turn open sub-screens) that, unless you follow the "left to right, top to bottom" flow of data entry, and click save often, ends up putting and/or fetching incomplete data to/from the database; or dropping data altogether that you just entered. Yes, our original coders are at fault, but so is CSLA... It just seems that there are so many moving parts to enable, control, and coordinate CSLA features. It's like having to deal with all the dials & switches of a fighter jet when all you really need is something more like a Cessna 152.
You will write lots of custom code to enable the CSLA features. For example CSLA will never be confused with object relational mapper (ORM) tools like Hibernate and Entity Framework. Our SAVE() methods are non trivial, so are the trivial ones.
Encouraging the use of code generators compounds problems. We used CodeSMith to generate classes from data tables. So we end up with code that has a 1-1 correspondence of table to c# class. So you must write all the code to handle dataStore to your "real" objects.
Data store/ and fetch is very inefficient w/ CSLA. Because of the Behemoth, monolithic BusinessObject-does-all-and-knows-all centric paradigm, objects end up doing a one-object-at-a-time data fetch and instantiate. Collections of composite objects significantly compound the problem. A single "get this object" always results in a cascade of separate data fetches (one or more for each individual object) to instantiate the entire inheritance & composite relationship chains. Its known as the "N+1 query problem." Oh, and fetching data ALWAYS results in a new object being created, even if we're only updating an existing one. No wonder our more complex screens are FUBAR.
It allows you to architect your application with solid object oriented principals and a good seperation of concerns.
Yes and no. Mostly no.
The BusinessObject handles it's own data storing. That is anti separation of concerns.
"It allows you..." well, yeah - so does a blank text editor screen, but does not force or encourage you like the MVC.NET framework does, for example. IMHO, CLSA provides absolutely zero benefit for ensuring that the code you develop with it follows "solid OO principles". In fact coders w/ weak OO skills (the majority, in my experience) will really stand out when using CSLA! Woe betide the maintenance programmer.
CSLA is the poster child for the solid object oriented principle favor composition over inheritance. CLSA code is untestable. Because an inherited framework BusinessObject is, does, and needs everything, all at once and every time, it's not likely that you will be able to get much test coverage. You can't get at the pieces because everything is tightly coupled.The framework is not amenable to dependency injection. It is an iron curtain of code.
Your code will be difficult to debug. Call stacks get very deep and as you get near the center of the sun so to speak, everything turns into reflection - "what *&^# methods just got called???" And you simply get lost. period.
EDIT 7 Mar 2016
What more insight can I add after the original post? Two things, perhaps:
First, It feels like CSLA has some promise. If we knew how to juggle all those moving parts together. But CSLA is so enigmatic that even things we have done right are corrupted over time. IMHO without a very strong team-wide CSLA wherewithal, any implementation is doomed. Without a vibrant "open source" of technical references, training, and community it's hopeless. In almost a decade our CSLA code, in my final analysis, is just compounding technical debt.
Second, here is a recent comment I made, below:
Our complexity often does not seem to fit in the CSLA infrastructure
so we write outside of the framework. This and cheap labor results in
rampant SRP violations and has me hitting brick walls managing dynamic
rule application, for example. Then, CSLA parent/child infrastructure
propagates composite object validation but we don't always want c/p
relationships, so we write more validation and store code. So today
our CSLA implementation is inconsistent & confusing. Refactoring to
more-better CSLA will have profound domino effects. So after that
initial injection CSLA is essentially abandoned.
end Edit
CSLA is business object framework that allows you to easily create business objects on top of a data layer. It allows you to architect your application with solid object oriented principals and a good seperation of concerns.
I would highly recommend you read the CSLA book by Rocky Lhotka called Expert C# 2008 Business Objects. That will not only teach you about the framework but also teach good software architecture principals.
You can grab the book here on Amazon
I suggest reading the What is CSLA? page, and browse through the CSLA .NET FAQ site.
For the latest published information check out the Using CSLA 4 ebook series.
In reply to #radarbob https://stackoverflow.com/a/10922373/261363, hope I won't regret this and start a flame war.
Our team has been developing a couple of LOB applications with CSLA. From my experience on writing green field apps with CSLA and maintaining existing code here are my replies to your points.
The BO is not suppose to do it's own data persistence, you will have a Factory that will handle all data persistance, for example using a ORM to map to Models that are later on saved.
Sorry to hear that, I make sure I study the framework documentation and write at least one toy application before committing to a existing code database. Furthermore you can even download and browse the CSLA code.
You have BO -> Portal -> Factories that should not be very complicated the existing CSLA examples go a long way on explaining what is happening on each level.
CLSA should never be confused with a ORM
As you should, business object are rarely mapped to one table and thus require a bit of work when saving. In the case they are mapped to one table to you use something like AutoMapper to map your BO to your POCO in 1 line.
Look into CSLA Commands, also is nothing stopping you from keeping your BO as small or big as you want as long as you keep in mind that they are not the same as the POCO's that you will persist.
In a project we worked on we where able to easily test BO to ensure that the business logic was correct. Because of the nice separation of concerns we tested our Factories in isolation to make sure that business objects will be persisted accordingly.
At one point I was able to easily persist part of my BO's in MongoDB so the application was running on a hybrid database MSSQL and MongoDB without having to even change one line of code in my business objects, all I had to do was to update the factories to use Mongo instead of the current ORM.
Hope this addresses all your points in a fair manner,
Regards
CSLA: Component-based Scalable Logical Architecture
A paragraph in a nutshell that described CSLA to me from the website was this:
CSLA .NET enables you to create an object-oriented business layer that abstracts and encapsulates your business logic and data. The framework ensures your business objects work seamlessly with all .NET interface technologies, including WinRT XAML, WPF, ASP.NET MVC, ASP.NET Web Forms, WCF, asmx services, Windows Phone 7, Silverlight, Windows Workflow and Windows Forms.
Why you might use it:
Business rule management. Once you learn the business rule system, it provides a way to enforce business logic in a tidy package. If you have an object with child objects that need to report Validation to the parent most level, there is a way to handle that. (see http://www.lhotka.net/weblog/CSLA4BusinessRulesSubsystem.aspx for more information on the rule system)
You have business objects that you need to support N-level undo? A CSLA BusinessBase has a baked in property management system (like dependency properties) for functionality like N-Level Undo (it is actually completely implemented.) (This also ties into the business rule management. You can fire validation when a primary property changes, or you can change a property based on the value of another property.)
Data portal management. This one was an interesting concept. If I need to execute data operations locally, CSLA is configured for this out of the box. I can also stand up a WCF service that references my business object libraries, and use a few lines of configuration to make a WCF endpoint to manage data operations. The WCF service is a part of the CSLA framework. It was neat to see this in action. Other scenarios? Sure! Your business object library doesn't need to change, the DataPortal class determines if it needs to execute remotely or locally, according to your configuration.
CSLA does force you to use a few mechanisms that may not feel natural at first. I think that is somewhat true of any pattern you choose to implement. However, when it comes to the challenges of implementing Service Oriented Architecture, CSLA offers a lot. Yes, you are going to have an architect level developer authoring some of your libraries. However, if you're building an enterprise class application, shouldn't you be doing that already?
CSLA, when architected correctly, is testable. We use the repository pattern to replace out the actual dal with a mock layer and test both by specification (using NUnit/SpecFlow) and in a unit fashion when appropriate.
As far as support, including Rocky himself, there is a community of contributors that ensure things like CSLA.Net for Xamarin become a reality. There are consultancies that know CSLA and use it on a regular basis depending on the scope of work (and no, not just the consultancy for which I work.)
All things considered, CSLA may not be for you. Like others have indicated, read the site and the books (especially Expert C# 2008 Business Objects.) Ask questions, as the CSLA community tends to give quality advice.
CSLA is described in detail here. The new book is a great starting point. As a great compliment to the book I would recommend checking out our CSLA 3.8 templates. Rocky recommends using a Code Generator, and we have the leading set of templates, that will get you up and running in no time.
Thanks
-Blake Niemyjski (Author of the CodeSmith CSLA Templates)