I was wondering if it was possible to have differences between my conceptual model and the class diagram?
In the conceptual model, I explain that the user can create a message.
But in the class diagram the user must go through a class that contains all methods of creating a "ManageMessage" message.
here is an example
Can you help me ? Thank you
It's up to you how you show your classes in different diagrams. So in one you can show detailed attributes and operations and in another you show just the class name. However, in most cases it's better to create domain model which focuses on business aspects in the beginning. It does not have technically imposed structural elements and mainly you use attributes (YMMV). Later you derive a technical design from that model where you create a copy that links back with <<trace>> dependencies (UML tools offer transformation for that). Although you have to (mostly) manually synch the two models it's best to communicate with either business and developers.
N.B. about your design above: A message with zero related users does not seem to make much sense. Also you should not use the shared aggregation since it has no defined semantics.
Related
Can someone explain me the difference between class diagram during analysis and design?
So far, I understand that the class diagram of design would be the real class diagram, with all methods and attributes (ready to become code), but what about analysis? Do I have to do a class diagram for every sequence diagram? Do I have to add methods and attributes at the design stage already ? Or only connection?
The UML class model is produced and refined iteratively as the understanding of the system increases. There's only one model for your system, although different diagrams may outline different aspects and level of details of this model.
Typically you would start with the domain model based on the requirements (e.g. use cases, user stories, statement of work, user interviews, etc.):
Top priority is to get an overview. So the first sketch would identify the domain classes and how they relate to each other.
You would then enrich this initial understanding by outlining in the diagram the key properties and methods that are essential to the understanding of the domain.
You would then enrich the model with more detailed design diagrams as you design your solution. So you would add any classes required for the implementation (e.g.user interface classes, application controllers, persistence layers, etc.).
Design diagrams are used to get a shared understanding about the software structure within the development team. So they should be easy to understand (i.e.focus on important aspects and not necessarily be cluttered with too many details that would anyhow have to be implemented in code and quickly be outdated if you don't have an army of analysts to update the model).
If you'd use an UML tool able to generate code or if you are contractually obliged to provide all the details in UML form, you would further refine the model with a fully detailed implementation diagram. Attention: for scholar work it is frequent that the teacher asks for a design diagram but expects in reality an implementation diagram.
We have 3 major types of class diagram in Object Oriented Methodologies.
Class Diagrams in Requirement (Domain Modeling)
Analysis Class Diagrams
Design Class Diagrams
Main difference of these class diagrams is their Abstraction.
In Domain Modeling, we use Class Diagrams. BUT, we do not use any Inheritance or any Interfaces, or any preforming analysis on the classes. We just write so little attributes of classes (about 3 attributes). we don't write any methods of classes. WHY? because of Abstraction. Main goal of Domain Modeling is modeling the domain. And detect Which classes should be in problem domain of system.
In Analysis modeling, we use class diagram. Classes in analysis is more detailed than classes in Domain. But it is not the final specification.
In Analysis, we determine Analysis Classes. We can use Inheritance between them. We can write their attributes and methods in detail. BUT, this phase is done by System Analysts. (Not System Designers or Programmer). Their profession is both knowing the Business Logics and Software Techniques. So they can write analysis classes in more detailed than Domain. However, they can not write very detailed as System Designers can.
In the other hand, we can use some analysis patterns to determine our Analysis Classes. For example RUP introduce Boundary/Control/Entity pattern. If we decided to use an existing analysis pattern, we can use the guidelines exist in the pattern documentations.
The guideline of Boundary/Control/Entity about the abstraction of classes are in this reference. In this pattern we should write only attributes for Entity classes and write only methods for Control classes and write attributes and methods for Boundary classes.
However, In my idea, we can follow the guideline or not. We can write more attributes and methods for analysis classes. What is happening? If our System Analyst try to write more detailed attributes or methods, what's happening:
I think that 1) our system analyst is not system analyst. maybe system designer. 2) we don't need their details. It is just time consuming for analysis phase. 3) ONLY if our analysis and design team are the same, or we combine analysis and design (like Agile Methodologies) the details in Analysis can be logical and useable.
In Design modeling, we use class diagram, this type of class diagram should be the final specification and should contain all attributes and methods. This classes are not conceptual. we can use all OOD technologies, Design Pattern and etc.
Can someone briefly explain the difference between a Conceptual Class Diagram and a Detailed Class Diagram?
While a "Conceptual Class Diagram" expresses a conceptual (domain) model, it's not clear what you (or your professor) mean(s) with "Detailed Class Diagram": it could refer to a (language-/platform-independent) design model or to an implementation model like a C++ class model or a Java class model.
See also my answer to this related SO question.
The one-to-many relationships between conceptual models and design models, and between design models and implementation models are illustrated in the following Figure:
As an example that illustrates how the derivation chain from concept via design to implementation works, consider the following model of a people/Person concept/class:
Domain models are solution-independent descriptions of a problem domain produced in the analysis phase of a software engineering project. The term "conceptual model" is often used as a synonym of "domain model". A domain model may include both descriptions of the domain’s state structure (in conceptual information models) and descriptions of its processes (in conceptual process models). They are solution-independent, or ‘computation-independent’, in the sense that they are not concerned with making any system design choices or with other computational issues. Rather, they focus on the perspective and language of the subject matter experts for the domain under consideration.
In the design phase, first a platform-independent design model, as a general computational solution to the given software engineering problem, is developed on the basis of the domain model. The same domain model can potentially be used to produce a number of (even radically) different design models representing different design choices. Then, by taking into consideration a number of implementation issues ranging from architectural styles, nonfunctional quality criteria to be maximized (e.g., performance, adaptability) and target technology platforms, one or more platform-specific implementation models are derived from the design model.
A conceptual class diagram is used to understand and analyze a problem domain. A detailed class diagram is a design artifact, where many things may have been optimized away. For example, every dog might bark, but a dog-salon application doesn't care, so it can optimize away that fact.
I don't know of any standard or methodology that defines both these concepts. For example, the UML specification does not mention them. I think every answer will be subjective. I will give my own answer, based on more than 25 years of experience with IT-related modeling.
In a conceptual class diagram, every class is a concept, usually related to the business domain, the real world, e.g. Customer, Order etc. It may also show concepts that cannot be directly found in the business domain, but are needed to model the functionality of a particular application, e.g. BackupCopy. These are concepts the user of the application must understand. See also www.agilemodeling.com
There are other types of class diagram, e.g. class diagrams that model the source code, where every class corresponds to a Java class or a C# class, or class diagrams that model the physical database structure, where every class corresponds to a database table.
Each of these types of class diagrams may or may not be detailed. If a class diagram is not detailed, it typically does not show any attributes, or only the main attributes. If a class diagram is detailed, it shows all attributes relevant for the problem at hand and the data types of these attributes.
The concept of a conceptual class diagram is e.g. explained by Scott Ambler at http://www.agilemodeling.com/artifacts/classDiagram.htm#ConceptualClassDiagrams.
Basically "Conceptual" here means that the content of the diagram is taken from an analytic view point that takes the "concepts" of a domain and describes them.
For "concept" you could also say:
thing
item
aspect
object
topic
The conceptual diagram is basically what you get if you ask people for what problem they'd like to get solved by your software. So you analyze the situation/problem by asking questions that will help you create you diagram:
what are the things that are relevant? - these will be your candidates for classes
what are the features of those things? - these are the candidates for your attributes
how are the things releated to each other - e.g. is one part of another? Does it need the other? - these are the candidates for your relations
what should you be able to do with these things in your system ? - these are the candidates for your operations
In the past this step was called OOA - object oriented analysis. The steps following this are OOD - object oriented design and OOI - object oriented implementation. Many years ago some authors proposed to create three different models for OOA/OOD and OOI. Therefore you'd have different and usually more detailed diagrams for OOD and OOI. For the term "Detailed Class Diagram" i'd guess that one of the OOD and/or OOI views would be meant. Be careful though - some of the diagrams created this way will have patterns or pattern-like ideas as a basis. You'r diagrams would tend to be very repetitive and redundant if you keep capturing such patterns in concrete diagrams for every conceptual diagram. I'd rather recommend to give just one example of how to go from problem to solution and then comment "do it this way for all other concepts that are similar".
I'm studying for a reexam in OOAD and doing some old exam questions. I'm trying to develop an analysis class model that may be used to manage a restaurant's menus. Here are the requirements:
Several different menus (breakfast,lunch,dinner)
Dishes may exists in several different menus
The restaurant also provides catering
Dishes should keep information which is relevant for guests with special requests (vegetarian,allergies etc..) Special menus may be created using this information as search criteria.
How I should model the catering? Should there be a Menu class and then breakfast,lunch,dinner and special as specialization classes or should I just have one Menu class? Should there be specialization classes for vegetarian,gluten free..etc dishes?
Then I have this question which confuses me a bit..
"What are 4 tasks that must be addressed when you transform this analysis class model into a design model?"
What is meant by this? Are there 4 general tasks/steps that always should be done when translating an analysis model into a design model or is it 4 specific tasks specifically for this analysis class model?
I've looked thorugh the presentations and the book (OOAD with applications) and the only thing I found related to these 4 steps/tasks was in a case study:
■ Identify the architectural elements at the given level of abstraction to further establish the problem boundaries and begin the object-oriented decomposition.
■ Identify the semantics of the elements, that is, establish their behavior and attributes.
■ Identify the relationships among the elements to solidify their boundaries and collaborators.
■ Specify the interface of the elements and then their refinement in preparation for analysis at the next level of abstraction.
Regards
How I should model the catering? Should there be a Menu class and then breakfast,lunch,dinner and special as specialization classes or should I just have one Menu class? Should there be specialization classes for vegetarian,gluten free..etc dishes?
You should be modeling your business requirements. In your case, the requirements you have are from your exam task only. So you will have to decide what you include in your model. Only include in your business domain model what you think you will need to hold a state, or perform an operation on.
Should there be specialization classes for vegetarian,gluten free..etc dishes?
Should be possible to save that in a simple boolean flag in the meal class, don't you think?
The "4 tasks" question is open for interpretation and is probably best answered when you have the documents from your studies available. At least I'd consider the 4 tasks you list a reasonable answer to the question.
Welcome to StackOverflow.
If you post your modeling attempts as a image file, you may receive more detailed help. You may use a service like dropbox to reference graphics until you have enough reputation for uploads to SO.
Class diagram by myself,for reference.
If I create a conceptual class diagram such that each class captures 'name' and 'attributes' but not 'operations', have I not basically created what would be otherwise considered an ERD? I'm trying to gain an understanding of what the differences are between creating a conceptual class diagram as I have described versus calling it a ERD? If these are still two different animals, can somebody please explain what the differences are?
The class diagram contains just the classes in your object model with eventual links/relationships connecting diagram elements. However those links don't necessarily correspond to physical relationships like in an ERD diagram, but instead they represent logical connections.
The class diagram is just the object model of your application and does not contain any persistence-specific information. When you think about the class diagram forget about the database or any other storage you may use.
The ERD diagram on the other side, is a persistence-specific diagram which display the entities (tables) existing in a (most often) relational database. It also displays the physical relations (and cardinalities) between those tables and all other database-specific information. The ERD diagram can sometimes look similar to the class diagram, but that doesn't mean is the same as a class diagram.
There´s little difference in the expressiveness of both (if we just focus on the attributes, classes and associations part) if you use Extended Entity Relationship diagrams (the most common case nowadays)
True, they look very different at the graphical level since they use different symbols for the elements but the "semantics" are quite similar. They both allow inheritance (again, I´m talking about EER), n-ary associations, association classes, ...
The ER diagrams I've seen (most frequently ERWin IE notation) have focused on the design for a database. They are concerned with primary keys, foreign keys, have unnamed relationships, and usually have no generalization / specialization.
A good UML conceptual class diagram, on the other hand, is not concerned with keys, reflects the problem domain, and has association-end properties that at least hint at the semantics of why things are related. This helps communicate the domain down to more junior developers so they don't have to guess.
It depends on the situation where you may not like to do the ER-D. But imagine if you have a seperate data layer where the data logic is handled. In this case many details of data shall not be shared with the application layer. And you class diagram shall not go beyond the application layer. I must stress that both the diagrams are not equal. And there are situations where you need to do both, mainly in multi-tier architecture, and there are situations where you may be able to just use class diagram; e.g. single-tier application.
I strongly advocate the view that class diagram doesn't abrogate the E-R diagram.
Design class diagrams are made from conceptual model and collaboration diagrams.
Design class diagrams include:
Classes, associations and attributes
Methods
Types of attributes
Navigability
Dependencies
IMO In Simple terms
Class diagram depicts the details of how will the system work.
ER diagram depicts how the system persists 'state' as a blue print.
Goal:
Detail out state and behavior of the components(classes) of the system.
Design 'efficient', flexile system(less coupling and more cohesion) using Solid principles.
Goal:
Design a blue print of how to 'efficiently' persist the state of the system.
Consider what kind of queries will be made (read vs write), are there any joins required
consequently figure out the columns for indexing
Use Normalization, ACID properties.
PS: notice the both the diagram tries to efficiently do thing in their on respect.
Can anyone tell which UML diagram I should change if there is a slight change in the design of application.
The change is -> Earlier the application was using Active directory for authentication now I want to use the Membership provider instead.
I want to keep the change minimum in diagrams.
Thanks
Sounds like component diagrams or class diagrams. Check out the following topics and illustrations for VS 2010 Ultimate RC:
UML Component Diagrams: Reference at http://msdn.microsoft.com/en-us/library/dd409390%28VS.100%29.aspx:
A component diagram shows the parts of a design for a software system. A component diagram helps you
visualize the high-level structure of the system and the service behavior that those pieces provide
and consume through interfaces.
UML Class Diagrams: Reference at http://msdn.microsoft.com/en-us/library/dd409437%28VS.100%29.aspx
A UML class diagram describes the object and information structures used by your application, both
internally and in communication with its users. It describes the information without reference to any
particular implementation.
It will surely depend the diagrams at your disposal. Sound like a correction in one of the static diagram types, like the component diagram ...
This of course depends on how you structure your documents and your uml-diagrams.
In general I have a Conceptual model, Class Diagram and a Design Diagram which are diractly linked to the architecture. And then you should in most cases have System Sequence Diagrams and more. However, depending on how your structure is and to minimize the "changes" required.
I would suggest that you use something more generic for the parts that might be changed. Active Directory Authentication and Membership Provider Authentication is both Authentication methods, which means that you can, instead of displaying the whole sequence at the Authentication step, just use "Authentication".
Now, in the conceptual models and in the design + class diagrams, you will need to change and add some fields, tables or whatever is added. But it shouldn't matter if you need to add more or less, because the documents need to reflect upon your software as accurate as possible.
So, to minimize changes, use more generic types.