UML notations says, Usecases are drawn to point out the functional requirements in the Problem Domain, it by no means gives the information about object or class as Data Flow Diagrams or Entity Relationship diagrams. But also why do we use Usecase Diagrams in object oriented analysis and design even if Usecases are not considered as Object oriented.
Use case diagram is meant to shed light on the main functionalities of the system , and emphasis the perspective presenting the latter as a blackBox merely existing for a sole mission;deliver to the actor the Promised service .
At this point we don't realy care about OOP realy , as you can definetly use Use case diagram for any other type of analysis.
UML is just a set of visual tools to allow a unified expression of different perspective of the system.
In Case you are using The Unified Process it advocates to start with identifiying the use cases first then explode every use case into collaborative entities (classes) and establish the static collaboration between them by harnessing the Class Diagram toolbox.
Object-oriented is analysis and design methodology, while use case is requirements methodology.
And be aware of the core development workflow：
Business modeling
Requirements
Analysis
Design
If we use UML to do these works, we may have:
Business use case+ Business sequence diagram
System use case+ System use case specification
Analysis class diagram+ Analysis sequence diagram+ Analysis state machine diagram
Code, Database......
UML diagrams in 3. can be replaced by DFD/ER
Kirill Fakhroutdinov's online book uml-diagrams.org defines UML as
The Unified Modeling Language™ (UML®) is a standard visual modeling language intended to be used for
modeling business and similar processes,
analysis, design, and implementation of software-based systems
UML is a common language for business analysts, software architects and developers used to describe, specify, design, and document existing or new business processes, structure and behavior of artifacts of software systems....
As such the language needs words to describe processes, their actors (the code and its users, why the code exists, what is it good for, why someone should pay a money for it..)..
If in your designs you don't need to take users and their needs into account (you have the user interface designs set and you are focusing just on a library code) then don't bother, use UML to describe the parts you are dealing with and use diagrams that are natural and useful for you (and your teammates)
Some related articles:
http://www.uml-diagrams.org/use-case-diagrams.html
http://www.jamasoftware.com/blog/when-use-cases-arent-enough-part-1/
http://agilemodeling.com/essays/agileRequirements.htm
http://www.sparxsystems.com/downloads/whitepapers/Requirements_Management_in_Enterprise_Architect.pdf
http://alistair.cockburn.us/Stop+confusing+use+cases+and+user+stories (and http://c2.com/cgi/wiki?UserStoryAndUseCaseComparison)
If well use cases diagrams are mainly intended for communication with non-technical people, I would like to add that in some software architectures (like Clean Architecture), use cases are represented as actual objects that orchestrate the entities (they are equal to services after all).
Eg.
Given the use case "Submit Issue", you can create the following definition for it:
Submit Issue Use Case
Input data:
issue_id
issue_description
date
Output data:
same input data as confirmation
Primary Course
Validate input data
Create new Issue instance using the input data
Persist new Issue
return confirmation data
As you can see in the Primary course, there is even a detectable dependency between this use case and an entity object named "Issue".
A python example for this SubmitIssue Use Case class:
class SubmitIssue(UseCase):
def __init__(issue_repo):
self._repo = issue_repo
def execute(self, input_data):
#validate input data as needed
#and apply branching logic if it is valid
new_issue = Issue(input_data) #create new issue
self._repo.add(new_issue) #persist new issue
return self._generate_output_data(new_issue)
#staticmethod
def _generate_output_data(new_issue):
#logic that returns the output data as specified
#in the use case output data definition
return output_data
regards.
Related
In the Vaughn Vernon's Domain-Driven Design Distilled book we can read that we should try to avoid creating technical abstractions that are perhaps too abstract and try to be more explicit by sticking to the concepts of the Ubiquitous Language.
Where I work we've built several tracking applications and in almost every of them there is the problem of having multiple specializations of the same thing, most likely with common behaviors, but different data and validation rules.
For instance, imagine an incident logging application where various kind of incidents are reported over the phone (e.g. car accident, fire, robbery). The information gathering process is similar to every incidents, but the captured data may vary widely as well as the validation rules that constrains this data.
So far, we have always solved these kind of problems with very technical abstractions (this is an oversimplified model, but you should get the idea):
As you can see, the DataValidationRules, DataFields and DataEntries abstractions have very little to do with the business of incident logging. Actually, they are part of a very generic solution to the problem of representing multiple entity specializations with different data in any domain.
I'd like to move away from this kind of very abstract model, but at the same time I do not see what would be the correct approach in making the business concepts explicit. I understand that the answer would be different in every domain, but in essence, should I be looking into having a single class per specialization? E.g. CarAccidentIndicent, FireIncident and RobberyIncident?
With a very limited number of specializations it seems like it could be manageable, but what if I have hundreds of them?
What about the UI? That means I'd have to move away from a generic way of generating the UI as well.
After thinking a little more about it I think I may have found a better and simpler way to express my concerns when it comes to DDD, OO and modeling many specializations.
On the one hand I want to come up with a model that is faithful to the Ubiquitous Language (UL) and model domain concepts explicitly. On the other hand I'm trying to respect the "favor composition over inheritance" mantra I'm so used to apply.
It seems that boths are conflicting because in order to enable composition I'll have to introduce abstractions that are most likely not part of the UL (e.g. Entity--Field composition) and when it comes to explicit modeling I do not see any other way than inheritance with one class per specialization.
Am I wrong in trying to avoid inheritance to represent hundreds of specialized entities that mainly differ in terms of data structure, not behaviors?
Then again, assuming they did differ a lot in terms of behaviors as well I'd have the same dilemma.
Just to be more explicit on the design choices:
In one scenario, composition would be achievable dynamically without requiring multiple classes per specialized compositions:
class Incident {
Set<Detail> details;
IncidentType type;
}
interface Detail {
public DetailType type();
}
class SomeDetail implements Detail {
...
}
class SomeOtherDetail implements Detail {
...
}
In the other scenario compositions are static and do require one class per specialized composition:
class CarAccidentIncident extends Incident {
SomeDetail someDetail;
SomeOtherDetail someOtherDetail;
}
class SomeDetail {}
class SomeOtherDetail {}
Obviously, the second approach is more explicit and offers a natural home for specific behaviors and rules. In the first approach we would have to introduce some abstract and technical concepts like Operation and DetailValidation which may not align well with the UL.
With a small number of different specializations I'd probably choose the latter without a second though, but because there are many of them it seems like I'm leaning more towards dynamic composition (even thought being dynamic is not required). Should I?
When to use DDD?
The thing is, DDD is not necessarily the right fit for all systems. It's particularly well suited to large systems with complex business rules.
If the business rules that need expressing to capture the essence of a FireIncident are simple enough to be encoded in a DataValidationRules record and a set of DataFields, then that suggests that perhaps those rules do not require the complexity of a DDD implementation.
The Domain of Data Validation
However, if you acknowledge that, you can shift your perspective towards intending to actually build a pure data validation engine. The domain of data validation should include entities such as data validation rules, and data fields, and would contemplate such questions related to the lifecycles of rules and fields - e.g. 'what happens if a validation rule changes - do all existing records that have previously been validated need revalidation?'
If the lifecycle of a data validation rule itself is complex enough to warrant it, then by all means, use DDD to implement that domain, although you may still choose to use CRUD if you find there are no complex rules or processes in the domain of data validation.
Who are your Domain Experts?
The further consequence of that is that your domain experts are no longer your end users (the people who know about car accidents and fire incidents) they are now the people (most likely specialists) who craft the validation rules and fields. If using DDD, you need to be asking them what types of rules they need and how they need the rules to work, and implementing using the Ubiquitous Language that they use to talk about the art and process of crafting validation rules.
Those people, in turn, would be 'programming' a next level system (you might say they are using a 4GL language tailored to the domain of incident logging) using your data validation engine. The thing is, their domain experts would be the people who know about car accidents. But the specialists wouldn't strictly be using DDD to craft the rules of a car accident, because they would not be expressing their model in software, but in the constrained language of your data capture and validation engine.
Additions following Update
Have been pondering this since your update and had a few more thoughts/questions:
Data Validation vs Entity Lifecycle/Behavior
Most of your concern is around representing data validation rules on create/update. Something that would help to understand is - what behavior/rules are represented by your entities other than data validation? i.e. in an incident management system, you might track an incident through a set of states such as Reported, WaitingForDispatch, ResponseEnRoute, ResponseOnSite, Resolved, Debriefed? In an insurance system you might track Reported, Verified, AwaitingFunding, Closed, etc.
The reason I ask, is that in the absence of such lifecycle behavior - if the main purpose of your system is pure data validation, then I return to my original thought of wondering if DDD is really the right approach for this system, as DDD brings greatest value when there is complex behavior to be modelled.
If you do have such lifecycles or other complex behavior - then one possibility is to consider the approach from the perspective of different bounded contexts - i.e. have one bounded context for data validation - which uses the approach you've described with more technical abstractions - as it is an efficient way to represent the validations - but another context from the perspective of lifecycle management, in which you could focus more on business abstractions - if all incidents follow similar set of lifecycles, then that context would have a much smaller number of specific entities.
Keeping entities sync'd between contexts is a whole 'nother topic, but not too troublesome if you adopt a service bus or event type technology and publish events when things change.
Updates to Validation Rules?
How do your business experts express requests for changes to validation rules? And how do you implement them? I'm guessing from what you've said, they probably express them in domain terms such as 'FireIncident'. But the implementation is interesting - do you have to craft data modification statements in SQL which get applied as part of a deployment?
Inheritance vs Composition
It seems that boths are conflicting because in order to enable composition I'll have to introduce abstractions that are most likely not part of the UL (e.g. Entity--Field composition)
I do not think this is true - composition does not have to require introducing technical abstractions. With either composition or inheritance, the goal is to distil insights into the domain to discover common patterns.
e.g. look for common behaviours or data validation sets and find the business language term that describes this commonality. e.g. You might find RobberyIncident and FireIncident both apply to Buildings.
If using inheritence you might create a BuildingIncident and RobberyIncident and FireIncident would extend BuildingIncident.
If using composition, you might create a valueobject to represent a Building and both RobberyIncident and FireIncident would contain a Building property. However RobberyIncident would also contain a Robbery property and FireIncident would also contain a Fire property. CarAccidentIncident and CarRobberyIncident would both contain a Car property, but CarRobberyIncident would also contain a Robbery property of the same type as the Robbery property on RobberyIncident - assuming they are truly common behaviours.
You may still have hundreds of classes representing specialised incident types, but they are simply composed of a set of value object properties representing the set of common patterns they are composed of - and those value objects can and should be in terms of ubiquitious language concepts.
My take on this is that not all information is pertinent to the domain.
I think that in many instances we try to apply techniques in an "all-or-nothing" approach whereas we may need to be focusing on the "right tool for the job". In the answer provided by Chris he asks the question "When to use DDD?" and mentions "The thing is, DDD is not necessarily the right fit for all systems." I would argue that DDD may not be appropriate for some parts of a system.
Would DDD be useful to create, say, a word processing application? I don't really think so. Although some good old proper OO would go a long way.
DDD is absolutely great for business behaviour focused bits of a system. However, there are going to be bits that can be modeled in a more technical/generic way that feed into more interesting business functionality. I'm sure that those incidents end up in some business process. An example may be a Claim. The business is very interested in tracking a claim and the claim amount, but where that claim came from isn't all too interesting. For all intents and purposes the "initiating documentation" may be filled in using pen and paper and scanned in to be linked to said claim. One could even start a new claim on the system using a plain text input.
I have been involved in a number of systems where a lot of peripheral data was sucked into the system but actually it wasn't really contributing much (law of diminishing returns and such).
I once worked on a loan system. The original 20 year-old system was re-written in C#. The main moving bits:
Client
Loan Amount
Payment schedule
Financial transactions (interest, payments, etc.)
All-in-all it is really a simple system. Well, 800+ tables later and stacks of developers/BAs and the system is somewhat of a monster. One could even capture stock and title deeds as guarantee. Now, my take would be to scan in some of this information and link it to the loan. However, somehow some business folks decide that they absolutely "must have" this information in the system. It isn't core though, I would say.
On the other end, another system I worked on calculated premiums. It was modeled quite business-like and was quite a maintenance nightmare. It was then re-written very generically by simply defining calculations that work on given inputs. There were some lookup tables for values and so on but no business processing as such.
Sometimes we may need to abstract moving bits into something that makes sense as an input or output and then use that in our domain. I think the UL should be used by ourselves and domain experts but it doesn't mean that we are not going to end up using technical concepts that are not part of the UL, and I think that that is okay. I'm sure a domain expert wouldn't care much for a SqlDbConnection even though we are going to using one of those in our code :) --- similarly we could model some structures outside of the domain proper.
In response to your update and question: I would not create a concrete class unless it really does feature in the UL in a big way. On a side note, I still favour composition over inheritance. I typically implement interfaces where necessary and go with abstract classes when inheriting, just to place some default behaviour when it helps.
The UL, as with any design, represents a model with nuances. We can apply DDD without using domain events. When we do use domain events we may even go with event sourcing. Event sourcing has very little to do with the UL in much the same way that the terms "Aggregate", "Entity", or "Value Object" would. The UL is going to be specific to the domain / domain experts and when we, as domain modelers, talk to each other we can describe various models in terms of DDD tactical patterns in order to bring across some of the specific UL concepts.
We have to listen to how a domain expert describes the problem space. As soon as we hear "When", as stated in so many other places, we know that we are probably dealing with an event. In much the same way we can listen to how a domain expert talks about the aggregates. For instance (totally bogus example):
"When a customer is registered we need to inform the supervisor of the CSR that initiated the request"
More loosely related to your example:
"When an incident takes place we need to capture some specific details regarding the incident. Depending on the type we need to capture different bits and validate that we have sufficient data to process our claim
Between these two we can see a distinct difference in how they are referring to interacting with the problem space. When a domain expert thinks of something in very broad terms I think it is prudent that we do the same.
On the other hand, should the conversation be more along the lines of this:
"When a car accident is registered we need to assign an assessor an wait for an assessment report that has to answer..."
Now we have something much more specific. These are, necessarily, mutually exclusive in that if they only ever talk about specifics then we go with "specific". If they first mention in broad terms and then specifics, we can also work in broad terms.
This is where our modeling is tricky to get right. It is the same nuance as we have in the Address as an aggregate vs value object "debate". It all depends on the context.
These things are going to be tricky and dependent on the domain in order to get right. As Eric Evans did mention: it may take a couple of models to get something that fits just right. This is necessarily so based on one's experience with the domain.
I have designed the domain models of my system by using class diagram. It only includes the business domain logic of my system but not application logic that will be affected by the choice of platform, tools and programming language. This is all right in the analysis stage because no implementation detail is required yet.
However, I found that the class diagram that I have designed in the analysis stage is not sufficient to be used as the blueprint to develop the system in the implementation stage due to the lack of application logic, presentation logic and persistence logic details. Do I need to re-design the class diagram or create another type of diagram to serve as the blueprint for implementation?
I did not have any real world experiences in designing and implementing a system from the start to end so I would like to have some insights on the role of class diagram in real world system development.
The book - Applying Use Case Driven Object Modeling with UML has defined analysis-level class diagram as the class diagram that includes domain models while design-level class diagram is the class diagram that is "closer" to the source code implementation. However, I could not find any example of design-level class diagram and do not know what should be included in the design-level class diagram.
This is going to be a long story, so I try to make it short. You were so far only on a certain level of abstraction. But once you reach the borders you need to extend your model. A good way it the use of Model Driven Architecture (MDA). Here you introduce 3 layers called
CIM Computation Independent Model,
PIM Platform Independent Model and
PSM Platform Specific Model
While the CIM only looks a requirements and use cases and talks about business the PIM concretes this layer and forms classes (the level you were looking at). Finally the PSM models concrete things as hardware where the system will be deployed.
There are quite a number of different processes which deal with creation of such a model. I once made a good start with ICONIX but RUP is also widely used (though much more complex).
I am beginning in UML and software analyse and i do not understand how UML and diagrams can influence coding and software architecture while we can directly build the code and its data base without diagrams.
I read lot of tutorials abouat the subject but not enough to understand the utility of UML in coding.
I understand everey diagram and its role. That is not my problem but i do not yet understand their roles after the analyse and design phase.
So what is the role of UML in coding phase of a software ?
Thank you.
The comment by #xmojmr already puts it right. UML creates a model (hence the M in UML) of a system. A model reduces information of a system to a level so it is a) manageable and b) complete. Human brains are not computers and you need a means of communication what the system is all about. You can do that as pure code, as paper document and as UML model. A combination of all is not uncommon. As long as you have tiny systems you can live with pur code and tools like Doxygen. But once it starts getting complex you need some handles. UML offers these to end users, architects, testers, developers, managers, etc. Along with UML you will also need a methodology. UML delivers the syntax how to document a system. But you need some structure above to write a nice novel.
UML-based models play an essential role for coding/implementing a software system in model-based (or model-driven) development. The basic idea is that you start making a model of your problem domain (the domain model), then you derive from it a platform-independent design model, which can be transformed into platform-specific implementation models (e.g. for Java- or C#-based platforms) that are finally encoded in the target languages.
The most prominent part of model-based development is the encoding of model classes (forming the model layer in an MVC architecture for apps) based on a data model (a UML class model) that has been derived from an information design model, which was obtained from a domain information model (where all these information/data models are UML class models).
You can find an instructive example of model-based development in my tutorial book Engineering Front-End Web Apps with Plain JavaScript.
This one is in my point of view a duplicate of that other question. It can't be flagged because there is no accepted answer. The related question on meta stackexchange does not provide a clear solution to that situation.
I think my personal answer was relevant and is applicable to the current question.
To be synthetic, Martin Fowler considers current uses of UML. I think he describe the current practices. Perhaps should these evolve ?
Perhaps would the initial question be the right place to discuss ?
I developing a 3 tier architecture for an MVC4 webapp + EntityFramwork5.
I want to keep separete the layer, so only DAL knows that I'm using EF, for example.
Actually I have a lot of classes to manage that:
DAL
Entity POCO
Entity DataContext : DbContext
Entity Repository
BL
Entity ViewModel
Entity Service(instantiate Entity Repository)
WEB
Entity Controllers (instantiate Entity Service)
This is working but is quite hard to mantain. I was thinking to remove the Entity Repository in DAL and use directly the DataContext (if I'm not wrong, after all DbContext has been desingned to be a Repository and a Unit of Work), but that will force me to add a reference to EntityFramework.dll in my BL. Is not a big issue, but I0m not sure it is the best choice.
Any advice?
(I hope I gave enough informations, if you need more, just ask)
You can use this this and this article.
An experienced Architect does not need to go through every single step in the book to get a reasonable design done for a small web
application. Such Architects can use their experience to speed up the
process. Since I have done similar web applications before and have
understood my deliverable, I am going to take the faster approach to
get the initial part of our DMS design done. That will hopefully
assist me to shorten the length of this article.
For those who do not have experience, let me briefly mention the general steps that involved in architecturing a software below...
Understand the initial customer requirement - Ask questions and do research to further elaborate the requirement
Define the process flow of the system preferably in visual (diagram) form. I usually draw a process-flow diagram here. In my
effort, I would try to define the manual version of the system first
and then would try to convert that into the automated version while
identifying the processes and their relations. This process-flow
diagram that we draw here can be used as the medium to validate the
captured requirements with the customer too.
Identify the software development model that suite your requirements
When the requirements are fully captured and defined before the design start, you can use the 'Water-Fall' model. But when the
requirements are undefined, a variant of 'Spiral' can be used to deal
with that.
When requirements are not defined, the system gets defined while it is being designed. In such cases, you need to keep adequate spaces
in respective modules, which later expansions are expected.
Decide what architecture to be used. In my case, to design our Document Management System (DMS), I will be using a combination of
ASP.NET MVC and Multitier Architecture (Three Tier Variant).
Analyze the system and identify its modules or sub systems.
Pick one sub system at a time and further analyze it and identify all granular level requirements belonging to that part of the systems.
Recognize the data entities and define the relationships among entities (Entity Relationship Diagram or ER Diagram). That can
followed by identifying the business entities (Some business entities
directly map with the classes of your system) and define the business
process flow.
Organized your entities. This is where you normalize your database, and decide what OOP concepts and design pattern to be used
etc.
Make your design consistent. Follow the same standards across all modules and layers. This includes streamlining the concepts (as an
example, if you have used two different design patterns in two
different modules to achieve the same goal, then pick the better
approach and use that in both the places), and conventions used in the
project.
Tuning the design is the last part of the process. In order to do this, you need to have a meeting with the project team. In that
meeting you need to present your design to your team and make them ask
questions about it. Take this as an opportunity to honestly evaluate/
adjust your design.
Just I am new to Object Modelling.I want to know still there is a need to use Sequence Diagram, Use case Diagram to develop an object model or any other new technology is available?
Update :
CRC (Class,Responsibilites,Collaborator) is very limited ?
It depends on the team or teams you're working with. The chief benefit of UML is that you can share diagrams with other individuals and teams without having to learn each others diagramming language. If the team you're working with doesn't know UML, it may not be worth going down that road unless everyone is interested and you know you'll be working together for a while.
In my experience UML sequence diagrams and object model diagrams are very usefully and generally understood by all. Sequence diagrams in particular have the ability to resolve design issues through the disipline of their construction. I haven't found use case diagrams to be as useful. Requirements are challenging and strongly dependent on human and organizational factors regardless of the methodology.
If you're communcating with non-technical stakeholders, UML is a waste of time because they won't have studied it. Use simple, well annotated diagrams. Colors are very effective.
If your team is all onsite, sometimes there's nothing better than a couple of whiteboards and a freeform diagramming style.
You don't necessarily need these items. They are just aids which are available if you choose to utilise them. They are particularly useful in a business environment where you need to articulate your architecture to fellow developers, but you can choose to use whatever you like, inc. your own personal standards or no standards at all!
"any other new technology is available?"
No.
UML pretty much dominates. A classic ERD is just a specialized class diagram that omits the method box from each class. Also, classic ERD's use crows feet instead of text annotation for cardinality and optionality. So ERD's are actually part of UML.
You can read about OPM, if you want something slightly different. They appear to combine an activity diagram and a class diagram into one thing: a process-data diagram.