I'm an information engineer student and I'm studying for an exam.
I have to replace nouns in use case in form of bulleted list with the name of the classes extracted with CRC cards.
I'm in trouble with that because I don't know how to do it right.
EXAMPLE A: "the system update the page" -> "Totem update the page"
Does CRC cards have to include classes that control the view?
Does this control must pass through a "controller" class like (in my case) "Connection"?
EXAMPLE A 2.0: "the system update the page" -> "Totem ask Connection to update the page"
Does CRC cards have to include classes that control the database?
EXAMPLE B: "the system add product in database" -> "Connection add object Product to Catalogue
Can someone help me to understand how to do this correctly?
Sorry for my English and sorry for the "strange" question
NOTE: ALL THE EXAMPLES ARE CREATED BY ME, SO I DON'T KNOW IF THEY ARE CORRECT
There's no direct relation
CRC cards and use-cases are two independent techniques:
CRC card are about classes, their responsibilities and their collaboration (with other classes). It is a tool that helps to explore potential classes and interactions between classes. It can work with any classes, including view classes and control classes.
Use-cases are goal oriented. The focus is on the reasons why an external actor may interact with a system. It is a tool that help to catch the purpose of a system and its boundaries with the external world. It is in principle independent of any internal classes.
Start to derive classes with an indirect relation
Use-cases can be mapped to classes, using the Entity-Control-Boundary technique. Let's imagine an actor Sales admin and a use-case Manage products:
every use-case is mapped to a specific control class, e.g. ManageProduct;
every link between an actor and a use case is mapped to a boundary class, e.g. ManageProductsForSalesAdmin;
identified business objects that matter to the the actors are also mapped to entity classes, e.g. Product.
Use the CRC cards to fine-tune the design
This could be the start for 3 first CRC cards, which would clarify clarify what class does what (including UI and DB persistence). You'd quickly find out that these initial "analysis classes" need to be broken down further and enriched.
For example:
the user interface may need different classes depending on your favourite framework. Therefore, break the ManageProductsForSalesAdmin down into more detailed classes such as ManageProductsView and ManageProductsListener or whatever is needed. If all the responsibilities of the initial card were moved to the new cards, you may retire it.
you may suddenly realize that a Product is associated to a ProductCategory: enrich your set with a new CRC card for the newly discovered entity.
the ManageProducts could require some specializations to deal with different behaviors such as CreateProduct, DuplicateProduct, ChangeProduct, DeleteProduct. Probably the initial card will keep some common responsibility and will co-exist with the more specialized ones.
You may continue to enrich your CRC set and play with the cards, until you’re satisfied with the classes and reached a stable split of responsibilities. CRC is ideal for iterative work ;-)
Additional comments
The main benefit of the EBC approach is its ability to relate classes to use-cases. This is not only a theoretical benefit, but also a very practical: if you change a class, you may then easily determine potential impact for the users (and points of attention for tests). So every time you create a new CRC card, you may simply keep a trace of the related use-case(s).
A final word on use-cases: “the system updates the page” is not a use-case: this is not a goal for an actor. It is some action the system has to perform in some larger context.
P.S: Sorry if this might come to late for your exam
Related
So, I have designed a use case for a student online system. The issue is that some of my base cases are subdivided into many included cases. For instance, to generate marksheet as a staff, my included use cases are: select student, select course, select module, select semester
In my class diagram, should i have methods for all of the smaller use cases or just the main one like generateMarksheet?
In short
No, that's not how it works.
Some more details
There is no direct mapping in general
Use-cases are about the requirements from a user perspective. So it's about the problems to solve. Typically they represent high level goals for the user such as Manage students or Subscribe to courses.
The classes of your system are about a technical solution that meet these requirements. In general however, there is no direct mapping as you describe: the behavior of the system emerge from the interaction between many classes within the system.
There are some methods to link both worlds
If you want a link between both worlds, you may follow the unified process that was promoted by the founding fathers of UML:
You start with your use-cases
You create an ECB class model for the analysis, in which you show a control class for every single use case, a boundary class for every association between a use case and an actor, and an entity class for every domain object that you can derive from the narrative.
You then think a little more about boundaries and controls, to see if there are some overlaps, or even reuse.
Then you think of designing your system. But the level of detail will be much higher. You'll end up mapping your own solution classes to the analysis classes for the purpose of traceability: for every class you can find back the use-case(s) to which it relates. And conversely.
But this approach has lost traction in an agile context. And also because solution design is often heavily influenced by architectural models chosen (such as MVP, MVVM, clean architecture,...) and these have a different logic than ECB (despite some apparent and misleading similarities), so that this analysis step is not adding sufficient value.
Morover, agile methods try to avoid a big up-front analysis that is required for a rigorous ECB approach.
I've never made a use-case diagram before so I'm wondering if mine is correct or not.
In short
This is an (almost) valid use-case diagram. But this does not make make them good use-cases. But what matters in the end is if it is useful to you.
More details
Is it formally correct according to UML?
UML is value-agnostic and defines UC on page 637 of the specs (highlight by me):
A UseCase is a kind of BehavioredClassifier that represents a
declaration of a set of offered Behaviors. Each UseCase specifies some
behavior that a subject can perform in collaboration with one or more
Actors. UseCases define the offered Behaviors of the subject without
reference to its internal structure. These Behaviors, involving
interactions between the Actors and the subject, may result in changes
to the state of the subject and communications with its environment.
Let's check the validity of your UC in view of this definition:
Start game, move paddle, restart game, and exit game are behaviors that the game (subject) offers in collaboration with the player (actor). These are valid UC according to UML.
Ball falls, hit all bricks, hit brick, and display score are behaviors that are more questionable: they do not require a collaboration or an interaction with the player. You could nevertheless argue that these make sense only if the user observe these behaviors, so there is an interaction with the player. So it could be claimed that these are also valid UC in regard of the UML definition.
Add score seems to be a purely internal behavior that is done without the user and not even observed by the user. This would not be a valid UC. However labels might be misleading: if Display score would mean the final game-over score and Add score would mean an update of the score on the screen, it could again be argued that it's a valid UC.
The use of extension (optional) and inclusion (systematic) seem also correct.
Is it a good UC?
While UML is value-agnostic, many authors define a use-case in a more ambitiuous way. In particular Ivar Jacobson, the inventor of the Use case defines it as:
A use case is all the ways of using a system to achieve a particular
goal for a particular user. Taken together the set of all the use
cases gives you all of the useful ways to use the system, and
illustrates the value that it will provide.
According to this definition, there is only one single use case here:
Play a game : this is the goal of the user that brings him/her value.
All the other elements are only ways of using the system to achieve this goal. So they belong to the single use-case. A approach would be to represent them as detail of the use-case description:
One suitable way would be to show these in terms of intent in an essential use-case. This approach was invented by Constantine and Lockwood in 1999. It is used centered and leaves full flexibility about the sequence of actions in the user interface.
Another modern way is the Use-Case 2.0, invented by Ivar Jacobson in 2011. These detailes would be shown as use-case slices, in a very similar way than user-stories.
Is this UML consistent with the text below?
Instead of trying to either define many subclasses or introduce
multiple inheritance, we can instead define a set of roles that the
device is meant to play. (It should be noted that this is another
reason why the concept of a managed device is a good one – now, we can
define a base concept of a managed device, and model its functionality
by associating one or more roles to it as appropriate). This solves
the mess of having the same generic function (such as routing)
assigned to two different types of devices that implement that same
generic function in different ways, producing different subsets of
functionality.
I believe that the UML specifies that each Device can have 0 or 1 DeviceRoles. A colleague asserts that the UML specifies that each DeviceRole can belong to a maximum of one Device. In either case, the UML seems to not reflect that a Device can aggregate a set of roles.
The UML and text is extracted from TMForum's Information Framework (SID):
Physical Resource Business Entities
Information Framework Suite
GB922 Physical Resource
Release 15.0.1
November 2015
Thanks, Greg
The UML diagram is consistent with the text. It clearly says that the device aggregates zero or more device roles and a device role can be played by zero or one device. In UML, multiplicity is notated adjacent to the type it quantifies.
It would help if the property names were written at the ends of the associations.
I have worked on this document and created a data model from it. In real world experience a resource, for example a physical resource like a mikrotik router can have roles of a router and firewall at the same time. So the model has to let you fulfill the need of several roles for a single resource.
I hope this example will clarify the subject.
I have an assignment for school, where I have to create a domain model of a specific e-commerce site that delivers complete grocery bags to people's homes. (http://www.linasmatkasse.se/)
It's quite basic. Chose a bag, create account (with info), pay.
My question is, what exactly should be included in the model (in general)? In other words, where does the lines of the domain end? For instance, should delivery and suppliers be included? They aren't technically part of the website itself, by still play a role.
Thanks in advance!
What is domain
Let us take some theme/subject. It could be grocery delivery, satellites, swallows observations, anything. Let us name this theme "AAA"
domain model for AAA is a "profi IT" word for model for AAA. That's all.
All elements specific to AAA that you'll set in your model, belong to domain. I don't know, why the old good word theme is not used. It is a pity. But the term is already accepted.
So, delivery and suppliers are in your domain. And also much more specific words belonging to grocery. And to bags. And to people's homes - addresses, drive ways in and out - everything that is relevant to your theme.
The domain sets your vocabulary. And that one is really important - you should use the vocabulary used by your clients and not to invent new words, such as "domain" for "theme" :-)
And first you should define your Use case diagram, later- State machine diagram, Deployment diagram, Component diagram, Communication diagram, Sequence/Activity/Time/Interaction Overview diagrams, and at last - class, object and composite structure diagrams. You needn't make all of them, but SOME are necessary.
Every entity that models an entity in reality is a part of the domain. In your example, delivery and suppliers should be a part of the domain model. Basically any entity that has a defined behavior should be modeled as a part of the domain. Many times it seems like the domain model components aren't a part of the website and this is actually normal, the front-end is a way of viewing the domain model, it doesn't need to expose everything within the domain.
I usually find it easy to think about what entities are logical components of the business model in the real world and I only remove one if I find that it is redundant, unnecessary or can be encapsulated within another entity.
About the entities that are not the part of IT system
Do not ignore the pure human operations. On the contrary. Put them here, only their use cases will connect not actor-(sub)system, but actor-actor. And seeing them is very good for better planning the system as a whole. When ignoring them it is impossible to create a system good for user. The IT system is an integral component of the larger system, and we are creating the larger one really, with planning the support, processes, exchange of info, divisions and dependencies.
Too often had I problems with programmers who are blind to anything out of IT system border. And often it is impossible to make them think out of these borders. As a result, the system is blind to the real needs of the user, too. So we have that sad picture of user-hating software.
It is very useful to start to study the problem/domain/theme from entities that are out of the IT system, and to create firstly the diagram, that considers IT system as merely one of many blocks.
I am currently taking a course that gives an introduction to project planning. It is mostly about how to draw UML diagrams (blegh), but also has a few other topics.
One part in particular keeps bugging me. In the course they describe a method for going from a set of requirements to an initial class diagram, but everything about the method gives me this feeling that it is most definitely not the way to go. Let me first give an example before proceeding.
Let's consider a system that manages a greenhouse company. The company has multiple greenhouses, and every employee is assigned to his/her own greenhouse. A greenhouse has a location and a type of plant being grown in there. An employee has a name and phone number.
Here's what according to the course's method the class diagram would look like:
To me this looks like a database layout adapted for code. When I go about designing a program, I try to identify major abstractions. Like all the code that interacts with the database or the code that is responsible for the GUI are all different parts of the system. That would be what I consider to be an initial class diagram.
I simply can not imagine that this is a common way to start designing the architecture of a project. The classes look ugly, since if you take a slightly larger example the classes will be flooded with responsibilities. To me they look like data objects that have functionality to them they shouldn't have. It does not give me a clue on how to continue from here and get a general architecture going. Everything about it seems obsolete.
All I want to know if there's someone out there that can tell me if this is a common way to get a first class diagram on paper for reasons I am overlooking.
I would say it's reasonable to start with a logical model that's free of implementation constraints. That logical model is not necessarily concerned with physical implementation details (e.g. whether or not to use a database, what type of database, OS / UI choice, etc.) and thus represents just "real" business domain objects and processes. The similarity to a potential database implementation shouldn't be surprising for the simple example.
By understanding your business domain (through the logical model you've started to construct), you will be better placed to subsequently identify, for example, which architectural patterns are appropriate, what screens you need to build, and database elements to design. Possibly, there will be another part of the course that will aid you in this stage.
In practice, you will often know that you're intending to implement, say, a web-based application using MVC with a back-end database, and may look to model the implementation classes in parallel with your business items. For your course to use a method that emphasises the distinction between logical and physical stages doesn't sound unreasonable.
When I go about designing a program, I try to identify major
abstractions
Same principle in UML as well. You represent abstractions and their relationships and due to existing Visual Tools you can do a presentation of a system to stakeholders or even generate automatically stubs from your design.