Re: [UML Forum] understanding class/classifier,modeling/design

[H. S. Lahman]

Responding to Chriss...

When i read through UML specification there is two words i am not sure if both have the same meaning or not, those words are:    class and classifier

What is the differences between them?

This sounds like a homework problem. However, since OMG's meta model documentation is among the most obtuse in the entire technical space, I'll assume it's not.

Classifier is essentially a very generic element of the UML meta model that represents some sort of classification of things. Classes and Associations are more detailed (less abstract) classifications of things. You can think of the Classifier as a generalization of Class. The most obvious difference is the way that attributes are handled. A Classifier does not have intrinsic attributes. To express the notion that the things a Classifier describes have attributes, there would have to be a 1:* association between it and Attribute model elements. A Class does have intrinsic attributes -- essentially the Association and Attributes have been combined because there is no possibility of conditionality for a Class, which the more abstract Classifier allows.

also have another question:

What is the differences between modelling and design?

This REALLY looks like a homework problem. Modeling is about developing an abstract representation of something that a;ready exists. Design is about creating something new in the mind. Once you have created it, you may be able to model it.

-- 
Life is the only flaw in an otherwise perfect nonexistence
   -- Schopenhauer

Imagine how much more difficult physics would be if electrons had feelings
   -- Richard Feynman

Rene Descartes went into a bar. The bartender asked if he would like a drink. Descartes said, "I think not," and disappeared.

H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
software book: Model Based Development, Addison-Wesley, 2011
geology book: The Evolution and Utilization of Marine Resources, MIT Press, 1972

[Thomas Mercer-Hursh, Ph.D.]

On 4/14/2013 2:42 AM, Chriss wrote:
> *Which one of these sentences is more appropriate? design class
> diagram or model class diagram?

I would say neither.

One models X (something in the real world)
One designs software (to implement the model of X)
One draws a UML diagram to document the model.
One translates the UML documentation of the model into software to
implement the system.

[David Glaser]

Chriss,

Before you ask us this question.  You need to answer some questions for us.

First question would be, "What is the purpose of a model?"  Look in the dictionary and tell us!

Next question is "What is a design?"  Again look it up!

How would you handle the tension of the need for detail in describing a system yet handle the need for understandability of the system?

-David Glaser

On 04/14/2013 03:42 AM, Chriss wrote:

Thank you for your answers

I just wanted to properly describe(in the textual form) my
UML diagrams(use case,class,etc.)

*Which one of these sentences is more appropriate?
design class diagram or model class diagram?

As i conclude from your answer that UML is for modeling as
its name imply,Does this right?
but what about design?i think i have misunderstanding.
While studying Software engineering process and working in
design phase we frequently use the word "design" for
example we say:designing software system using UML
does this right?

*could you please clarify the differences between modeling
and design through simple example

Regards

[ snip - abstracted away detail in the interest of understandability ]

[H. S. Lahman]

Responding to Mercer-Hursh...

I basically agree, except for a Catch-22. When developing software, one
is modeling the solution design rather than the real world (where the
problem has not been solved yet). Methodologically, one wants to cast
the solution design in terms of real world artifacts because that will
lead to a more robust design. IOW, one designs the software solution and
then models both the conceptual design and things in the real world.
Consequently, they really can't be separated and it tends to be an
iterative process.

[Thomas Mercer-Hursh, Ph.D.]

On 4/14/2013 11:12 AM, H. S. Lahman wrote:
> I basically agree, except for a Catch-22. When developing software,
> one is modeling the solution design rather than the real world (where
> the problem has not been solved yet). Methodologically, one wants to
> cast the solution design in terms of real world artifacts because
> that will lead to a more robust design. IOW, one designs the software
> solution and then models both the conceptual design and things in the
> real world. Consequently, they really can't be separated and it tends
> to be an iterative process.

Without disagreeing, might one say that the domain class diagram was a
model of the real world and the class diagram a model of the software
(which, in good OO should correspond closely to the real world, at least
with respect to those attributes and behaviors desired in the target
system)?

[H. S. Lahman]

Responding to Chriss...

>
>
> Q2/What is a design?
>
> solution:
>
> 1)Do or plan (something) with a specific purpose or intention in mind.

This is the verb form. The noun form refers to the high level,
conceptual view of the actual solution to some problem.

> 2)The phase of software development following analysis, and concerned
> with how the problem is to be solved.

This sounds like a Structured Programming view from the '70s, where
analysis was really part of defining requirements (i.e., you used
analysis to define what the actual problem to be solved was). In an OO
context, OOA means something quite different. It is actually part of the
design and the product of OOA is a solution that resolves all functional
requirements. (Nonfunctional requirements are resolved in OOD.)

>
> Q3/How would you handle the tension of the need for

> detail in describing a system yet handle the need for
> understandability of the system?
>

> solution:
>
> To the best of my knowledge, I will create a UML diagrams.

I think this is a little simplistic. When the UML model is an OOA model,
it provides more that simply a design description. The purpose of OOA is
to provide a step-stone between the computing space and the customer
space. So the OOA model resolves only functional requirements because
those can be readily expressed solely in customer terms. Thus the OOA
model provides a vital link between the customer domain and the software
domain. OTOH, the OOD model elaborates the OOA model by dealing with
nonfunctional requirements that are invariably tied to the computing
space (speed, size, usability, synchronization, etc.).

Thus one gets two benefits for separating OOA and OOD models. One is
modularization and focus on resolving quite different requirements
separately. The other is a chain of traceability of requirements from
customer domain to computing domain through the overall design.