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.
Related
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
I'm doing a college project where I'm required to create a class diagram to a school registration system. There I have included a Student class, a registrationUI Boundary Class and a registrationController controller class:
I have created a separate controller class called systemController to do the other tasks such as calculate bill, etc...
I'm asking if it's possible to join the systemController class with the registrationUI class.
ECB architectural pattern
It can be useful to realize that the ECB architecture pattern originates from the use case models:
a controller represent a use case (e.g. RegistrationControler for use case "Register Student"). A controller is linked to all the entites that are involved in the use case (can be several, e.g. Registration, Student and Course)
boundaries connect the use case with the involved external actors (e.g. RegistrationUI offers the user interface to the registration manager, or to a student if it's a self service system). So several boundaries can be linked to a controler (for example if a secondary actor is involved such as a third party system).
entities represent domain objects (e.g. Student). So an entity can be linked to several other related entities (e.g. Registration record for the Student in a Course)
Consistency check
At the bottom of this article or that article you'll see a short matrix showing the possible relations between entities, controls and boundaries.
According to this logic, entities [should never be directly connected to a boundary. So your Access relation between Student and RegistrationUI is not a good idea (ECB is not MVC).
One boundary and two controllers ?
If you follow Jacobson's OOSE logic of decomposing a use case into boundaries and controllers, or if applying a basic step by step robustness analysis in a use case driven modeling approach, you'd identify the controllers (use cases) and create a boundary for each link between an actor and the use case. So at first sight, one could think that a boundary can be linked to at most one controller.
But you there are also "included" use cases or "extended" use cases. These are not connected directly to an actor, at least not explicitly in the graphic. This means that you could very well have one boundaries related to several controllers. In this tutorial you have a very nice ATM example with one boundary and several ATM transactions. In the DDJ article link above, you also have a similar example.
P.S.: Personally, I'm not quite sure what you want to achieve with the systemController. I suggest that you think about its role and its name. Looking at it's content, I could imagine that it's a part of the RegistrationController. Bt I could also imagine that it's a dispatcher launching the other controllers.
According to the book I am reading, in the three layer architecture (presentation, application ,storage), storage layer is responsible for looking after the persistence storage of data in the system. If so, I think entity classes are in the application layer.Is that correct? What classes will be in the storage layer? What is the difference between entity classes and the classes of storage layer? Can you please give me some examples?
There is not one truth here. People have different opinions and have their own definitions.
You have tagged your question with the UML tag, but UML does not define such things like "storage layer" or "entity class".
You have tagged your question with the "ecb-pattern" tag, but this pattern defines logical layers and does not prescribe a certain physical layering and vice versa, a physical layering does not prescribe a logical layering. The three-tier architecture you mention is probably a physical layering. Each physical layer may or may not use the ecb-pattern. This is a decision made by the software architect.
Most authors define the storage layer as being implemented by a database management system (DBMS) usually relational (RDBMS), where object-oriented notions like classes are not used. In that case, if the ecb-pattern is used, entity classes are part of the application layer and/or the presentation layer.
Example 1: The entity class Person could be a class in the application layer, which persists itself by sending a SQL message to the RDBMS (= storage layer). Class Person typically also implements business rules like "date of birth should be in the past".
Example 2: The entity class Person could be a class in the presentation layer, which persists itself by sending a message to the application layer, where the ecb-pattern is not used (suppose).
Entities are the low end database "parts". They represent the bits and pieces you put in the data storage for persistence. UML uses a stereotype which resembles a tape/head (if still someone remembers what that is):
The stereotypes for a boundary resemble a screen (or you can think of that being some projection). A boundary presents some information to an actor.
The control stereotype resembles a turning wheel (where you think of work being done) and it hides the business logic which react no boundary events and changes/reads entities.
You can also use rectangle notation:
Edit As #www.admiraalit.nl notes, this notation is not part of Superstructures itself (so not basic UML) but a common used notation in various UML profiles.
I am trying to understand how to classify the classes as boundary/control/entity classes. I can understand boundary and entity classes although my understanding may not beperfect. Boundary is the classes which interacts with the user. So the classes used for the userinterface will be boundary classes. Entity class handles data. So entities I use in the ER diagram will be entity classes. But I understand nothing why control object is used. It is said that control object is used to encapsulate domain functionalities. What if the control classes are not used. Can you please explain me with example.I found some explaination but I am still confused.Why boundary should not interact directly with entity? There are also classes which are not boundary/control/entity. What are they?
Background
The Entity/Boundary/Control approach was introduced by Ivar Jacobson in 1992 as part of his use case driven Objectory development method.
At that time Jacobson used the terminology Entity/Interface/Control. The strange circle notation that you can find in relaction with ECB was already used in his books in 1992 and in 1994. By the way, the use case of his methods were integrated into UML and his development process was merged into RUP, when Rational acquired Objectory.
The idea behind his method was to adopt a very logic and formal and deductive analysis and design approach. It starts with identifying the systems behavioral requirement with use cases. Each link of use case to the outside world would then be represented as an interface object responsible for encapsulating completely the user interface.
Each use case would be represented as one or several control objects:
Control object: An object that encapsulates functionality of one or
several use cases - I.Jacobson in The Object Advantage, ACM Press, 1994
Finally the business objects managed by the system can be partly inferred from the use cases, and during the analysis.
Additional information
The fundaments of the Iconix process were introduced in 1999 as part of the book "Use Case Driven Object Modeling with UML" by Rosenberg & Stephen. Some additional robustness constraints were introduced, certainly to improve separation of concerns. For example, the direct link between entity and boundary is prohibited. Everything has to be channelled through control objects:
Control objects (which we usually call controllers because they often
aren't real objects), serve as the "glue" between boundary objects and
entity objects - D.Rosenberg, in the linked DDJ article.
They add a recommendation to clarify the intent :
Both boundary objects and entity objects are nouns, and controllers
are verbs.
Conclusion
So the principle is that the control object represents the business logic offered by use cases, interacting on one side with the boundaries, and on the other side with the entities. Control objects can't be invoked/accessed directly by the outside world.
If you would want to avoid the control objects, you would have a boundary objects with methods corresponding to the verbs/functions/use-cases that your system is supposed to provide. This wouldn't be according to the modern ECB, but perfectly valid according to Jacobson's original approach. Nevertheless your boundary would no longer comply with the single responsibility principle of a SOLID design.
Boundary interact with actors (e.g. users).
Entity classes represent data.
Control mediates between the boundary and the entities (e.g. executes an operation on the entities)
Source: http://www.cs.sjsu.edu/~pearce/modules/patterns/enterprise/ecb/ecb.htm
The control classes contain the business logic. It's the most important part of a system. While the boundary just controls whether the text is green or blue (very basically) and the entities control whether data is stored in text files or databases (also very basically) the control classes do all the business logic. What to change in the entity when the boundary send mouse/keyboard events an vice verse what to show from the entities in the boundary.
In Domain Driven Design, domain services should contain operations that do not naturally belong inside an entity.
I've had the habit to create one service per entity and group some methods inside it (Organization entity and OrganizationService service).
But the more I think about it: OrganizationService doesn't mean anything, "Organization" is not a service, it's a thing.
So right now I have to add a Organization deep copy functionality that will duplicate a whole Organization aggregate, so I want to put it in a service.
Should I do: OrganizationService::copyOrganization(o)?
Or should I do: OrganizationCopyService::copyOrganization(o)?
More generally: is a "service" an abstract concept containing several operations, or is a service a concrete operation?
Edit: more examples given the first one wasn't that good:
StrategyService::apply()/cancel() or StrategyApplicationService::apply()/cancel()? ("Application" here is not related to the application layer ;)
CarService::wash() or CarWashingService::wash()?
In all these examples the most specific service name seems the most appropriate. After all, in real life, "car washing service" is something that makes sense. But I may end up with a lot of services...
*Note: this is not a question about opinions! This is a precise, answerable question about the Domain Driven Design methodology. I'm always weary of close votes when asking "should I", but there is a DDD way of doing things.*
I think it's good if a domain service has only one method. But I don't think it is a rule like you must not have more than one method on a domain service or something. If the interface abstracts only one thing or one behaviour, it's certainly easy to maitain but the granularity of the domain service totally depends on your bounded context. Sometimes we focus on low coupling too much and neglect high cohesive.
This is a bit opinion based I wanted to add it as a comment but ran out space.
I believe that in this case it will make sense to group the methods into one a separate OrganizationFactory-service with different construction method.
interface OrganizationFactory{
Organization createOrganization();
Organization createOrganizationCopy(Organization organization);
}
I suppose it will be in accordance with information expert pattern and DRY principle - one class has all the information about specific object creation and I don't see any reason to repeat this logic in different places.
Nevertheless, an interesting thing is that in ddd definition of factory pattern
Shift the responsibility for creating instances of complex objects and
AGGREGATES to a separate object, which may itself have no
responsibility in the domain model but is still part of the domain
design. Provide an interface that encapsulates all complex assembly
and that does not require the client to reference the concrete classes
of the objects being instantiated.
the word "object" is in a generic sense doesn't even have to be a separate class but can also be a factory method(I mean both the method of a class and the pattern factory method) - later Evans gives an example of the factory method of Brokerage Account that creates instances of Trade Order.
The book references to the family of GoF factory patterns and I do not think that there's a special DDD way of factory decomposition - the main points are that the object created is not half-baked and that the factory method should add as few dependecies as possible.
update DDD is not attached to any particular programming paradigm, while the question is about object-oriented decomposition, so again I don't think that DDD can provide any special recommendations on the number of methods per object.
Some folks use strange rules of thumb, but I believe that you can just go with High Cohesion principle and put methods with highly related responsibilities together. As this is a DDD question, so I suppose it's about domain services(i.e. not infrastructure services). I suppose that the services should be divided according to their responsibilities in the domain.
update 2 Anyway CarService can do CarService::wash()/ CarService::repaint() / CarService::diagnoseAirConditioningProblems() but it will be strange that CarWashingService will do CarWashingService::diagnoseAirConditioningProblems() it's like in Chomsky's generative grammar - some statements(sentences) in the language make sense, some don't. But if your sentence contains too much subjects(more than say 5-7) it also will be difficult to understand, even if it is valid sentence in language.