Future of UML with OO Concepts

[somkiat puisungnoen]

Personally, I dont like stepping too much in academic, as you will lose the realistic for real world projects. That's why my research area was E-commerce systems and information security.

I think, if you make/work in standard step, you can adapt step/solution to use in real world project.

[Nicholas Cheung]

1. The Use Case Diagram

Basically, use case diagram is not new to UML 2.0, as it also exists in UML 1.x.

What is new about use case diagram is it adds multiplicity.

Nick

[somkiat puisungnoen]

Originally posted by Ko Ko Naing:

What are the advantages of flow diagram that is introduced by UML 2.0? Thanks...

Flow diagram or DFD (Data Flow Diagram)

DFDs show the flow of data from external entities into the system, showed how the data moved from one process to another.

But DFD don't have target for OO Language.

[Lasse Koskela]

Originally posted by Somkiat Puisungnoen:
You can draw UML diagram in follow phase of development process..

1. Use case diagram in Requirement phase

2. Class diagram, package diagram, Sequence diagram, activities diagram are draw in Design/Analysis phase.

3. Deployment diagram MUST draw before install project.

Note that not all process models say that you should draw X in phase Y.
The processes I mostly prefer don't care about which "phase" you're in but instead recommend drawing a particular diagram whenever you feel the need to do so. Diagrams should be tools, not something you "have to" do.

[somkiat puisungnoen]

Originally posted by Ko Ko Naing:


Is that soem kinda sequence diagram? I think Sequence Diagram can help the developers a lot to know how data will be processed through the flows...

Sequence Diagram



A Sequence diagram depicts the sequence of actions that occur in a system. The invocation of methods in each object, and the order in which the invocation occurs is captured in a Sequence diagram. This makes the Sequence diagram a very useful tool to easily represent the dynamic behavior of a system.

A Sequence diagram is two-dimensional in nature. On the horizontal axis, it shows the life of the object that it represents, while on the vertical axis, it shows the sequence of the creation or invocation of these objects.

Because it uses class name and object name references, the Sequence diagram is very useful in elaborating and detailing the dynamic design and the sequence and origin of invocation of objects. Hence, the Sequence diagram is one of the most widely used dynamic diagrams in UML.



[ September 07, 2004: Message edited by: Somkiat Puisungnoen ]

[Nicholas Cheung]

I think, if you make/work in standard step, you can adapt step/solution to use in real world project.

That's true for commercial world, however, it may not work for academic.

For example, in software testing, usually we will write the test plans according to the system's functions. One of the methodologies is that we need to test the equivalency. We cannot directly testing something, but as we know another way round, so we test whether the 2 results are equivalent. For example, I do not know tan(X) is really equals Y. Although you can get the answer from calculator, but it is also a program, how you know. Thus, some suggest that, since we know tan(X) = tan(180-X). If the two value from the same program gives out the same value, we believe it is correct, something like that (of course, it is a similifed example).

For real life example, we may not really know string X encrypted by key Y gives cipher X'. For testing, you may then use key Y to decrypt cipher X' to see whether this X is same as the original string. This is also one of the equivalent test. Researchers use lots of time to work with those theory, but in practice, I really wonder are there any majority will use these theories when they work with software testing.

The idea sounds good, however, will it worth to use is another story.

Nick

[somkiat puisungnoen]

However, backward reengineering is always what the world do.

In my work, this solution never use in all project.

Because i must create all diagram before coding/developement process.

[Nicholas Cheung]

Diagrams should be tools, not something you "have to" do.

I agree that sometimes, not all systems need those diagrams. Of course, if there are, the documents will be more expressive.

For example, if most of the modules of the system provide single function, why border to draw state diagram? Of course, if there are, the doc. will be more complete, however, worth or not is another story.

Nick

[Nicholas Cheung]

In my work, this solution never use in all project.

Because i must create all diagram before coding/developement process.

It depends on the culture and company policy. Of course, in IBM, they may not use backward reengineering.

But how about you have a medium-sized project for only 2 weeks time with 4 people only. Although you can argue that such time frame is not reasonable, however, software house always need to face this issue.

They wanna get most of the potential customers, and use a lower price to bid it (so that they can get the project) and give out the system with the fastest time.

Nick

[Warren Dew]

Rajan Chinna:

When do we draw UML diagrams in the project life cycle?

I think UML should be done at the same stage as the flow charts are done.

[somkiat puisungnoen]

Originally posted by Nicholas Cheung:

Basically, use case diagram is not new to UML 2.0, as it also exists in UML 1.x.

What is new about use case diagram is it adds multiplicity.

Nick

Reference Website
http://bdn.borland.com/article/0,1410,30166,00.html

[Rajan Chinna]

Can i relate my jsp page, java beans and database flow in a single sequence diagram?

[Nicholas Cheung]

Can i relate my jsp page, java beans and database flow in a single sequence diagram?

Depends on how you define the term database flow.

If it is simple presistent object, like Entity bean, or database object, you can put all components together in the sequence diagrams.

In addition, keep in mind that there is no CAN or CANNOT, unless you obviously violate the UML rules, there is only GOOD or NOT GOOD.

Nick
[ September 07, 2004: Message edited by: Nicholas Cheung ]

[Nicholas Cheung]

Reference:

http://bdn.borland.com/article/0,1410,30166,00.html

It is misleading in your original post.

What's New in UML 2?

Answer :

1. The Use Case Diagram

In such answer, I will feel that there is NO use case diagram in UML 1.x, while it is newly added in UML 2.0.

What I wanna point out/clarify is that, use case diagram is NOT new, but the multiplicity is.

And the reference link clearly said that it discuss about new element of the use case diagram in UML 2.0 including multiplicities and conditions on "extends" relationships.

Nick

[Ilja Preuss]

Originally posted by Nicholas Cheung:
Basically, I guess people who invent UML aim to put down all diagrams and flows before the coding pharse.

Well, you guessed wrongly.

The people who invented UML are the same who invented RUP. And RUP doesn't have a coding phase - in fact, coding is part of every of the four phases of RUP:

http://www.delphidevelopers.com/engineering/process/rup/rup_phases.JPG

[Mcgill Smith]

Can tools resolve conflicts between interacting refactorings?

thanks.

[Nicholas Cheung]

The people who invented UML are the same who invented RUP. And RUP doesn't have a coding phase - in fact, coding is part of every of the four phases of RUP:

Basically, I mean the very 1st beginning.

As RUP is iternative processes, designing the n+1 phase may be at the same time of coding the n phase. Thus, it will be overlapped.

But the very first beginning, no coding should be done before the 1st draft is released. And the phases should be matched.

Nick

[Mukesh Agrawal]

Hi Nick,

Thanks for the Information. I have no information about the "formal method" that you have told. So could you inform me about the sources where I could get information on it.

Mukesh Agrawal.

[Nicholas Cheung]

I have no information about the "formal method" that you have told. So could you inform me about the sources where I could get information on it.

There are lots of formal methods. For Object-Oriented formal method, you may refer to:
http://www.cs.ucsd.edu/users/goguen/sys/foops.html

We have also discussed this a bit in the thread:
https://coderanch.com/t/99065/patterns/Future-UML-OO-Concepts

Nick

[Mukesh Agrawal]

Hi,
Thanks for your guidance.
But will this book provide us with the complete solution of UML from the start of the Project till end ?

Mukesh Agrawal

[Nicholas Cheung]

Software development process and UML are big areas in fact. I dont think there can be a single bible that can cover all aspects in details.

For startup, you may consider to read:
1. Fowler's UML Distilled, for basic understanding of UML
2. Larman's Applying UML and Patterns, for more in depth info on iterative process development.

These 2 are famous book for OOAD area.

Nick

[Nicholas Cheung]

In addition, you may need other books for the following areas:
1. Software testing
2. Refactoring
3. Performance tuning
4. Integrated with legacy systems
5. and more...

Thus, you see, if there exists a bible, it should be more than thousands of pages!!!

Nick

[somkiat puisungnoen]

Originally posted by Mukesh Agrawal:
Hi,
Thanks for your guidance.
But will this book provide us with the complete solution of UML from the start of the Project till end ?

Mukesh Agrawal

I think, don't have books is have complet solution for soluve all problem/project. But you should be have standard knowledge of UML and RUB developement process.

Experience is very important to solve all problem.

[Mukesh Agrawal]

But DFD don't have target for OO Language.

Hi,
In DFD also we have the same data source and sink So we can always fetch the area between both source and sink.

So what advantage now remains in UML.

Mukesh Agrawal.

[Lasse Koskela]

Originally posted by Mcgill Smith:
Can tools resolve conflicts between interacting refactorings?

When you apply a single refactoring on your development machine, there are no "interacting refactorings" -- there's just the one you are doing. This leads me to believe you're referring to how two simultaneous refactorings performed by two developers are handled in the source repository?

If that's what you're asking, the best answer I can provide is "with communication and taking small steps". When you take on a refactoring that affects a lot of classes, let your team know. Stand up and say, "I'm going to refactor Foo out of Bar into the Bonk and make Fiz an interface -- is that alright with you guys?". Taking small steps and integrating frequently helps by making typical manual merges easier.

[Stan James]

Re when to do what models ...

We try to model just in time with just enough detail for the reader to do some task. It's usually immediately before coding the next story but it might be after starting to code the story and discovering it's trickier than you thought or after coding the story so somebody outside the project can understand what we did.

"Just in time" is open to debate. Before "agile" made it big conventional wisdom was that you have to model a very large fraction of your system in significant detail to avoid gigantic mistakes. Believers in "emergent architecture" design new bits as they come along rather than the whole thing first.

BTW: I go to many meetings with architects and vendors and see NO UML AT ALL. I see PowerPoint: 3-D shaded boxes and arrows and cute icons. The measure of success is communication, not conformance to UML and most of these slides work. (Generally the more senior the architect the less sense they make, but that's another discussion.)

Use UML any time you need to communicate something that happens to work in UML better than anything else. Or when your boss tells you to.
[ September 08, 2004: Message edited by: Stan James ]

[Mukesh Agrawal]

Originally posted by Warren Dew:
Rajan Chinna:

When do we draw UML diagrams in the project life cycle?

I think UseCases should be drawn in the early stage as it shows the scope of the System whereas the other UML Diagrams like Activity and Sequence Diagram could be made once the Analysis is completed but before starting coding. Because the person who is going to code is different from the one who has done analysis and so he will require the flow to code in a proper manner.

Mukesh Agrawal

[Ko Ko Naing]

Originally posted by Somkiat Puisungnoen:



Flow diagram or DFD (Data Flow Diagram)

DFDs show the flow of data from external entities into the system, showed how the data moved from one process to another.

But DFD don't have target for OO Language.

Of course, I know what DFD is... Well, at least I cannot graduate from BSCS and do MSCS without knowing what DFD is..

What I just wanna know is that if there exist some kinda difference between DFD introduced by UML 2.0 and traditional DFD that you provided above...

Hope it is clear...

[Ko Ko Naing]

Originally posted by Nicholas Cheung:

It depends on the culture and company policy. Of course, in IBM, they may not use backward reengineering.

But how about you have a medium-sized project for only 2 weeks time with 4 people only. Although you can argue that such time frame is not reasonable, however, software house always need to face this issue.

They wanna get most of the potential customers, and use a lower price to bid it (so that they can get the project) and give out the system with the fastest time.

Nick

I do agree with Nick in this issue... Once a few months ago, I did have to face a small project with such tight time frame and we don't have time for documentation and stuff... Just code on-the-fly and submit the working application to the customer(Hopefully with very less bugs )

In such situation, we might neglect documentation such as drawing this and that in a certain phase and stuff...

[Nicholas Cheung]

In such situation, we might neglect documentation such as drawing this and that in a certain phase and stuff...

In such sense, when we provide our documentations, it is already a backward reengineering.

Nick

[Stan James]

Originally posted by Ko Ko Naing:

What I just wanna know is that if there exist some kinda difference between DFD introduced by UML 2.0 and traditional DFD that you provided above...

I think you're talking about the new "activity diagram". See http://www.agilemodeling.com/essays/umlDiagrams.htm for this one and all the rest.

[Daniel Mayer]

Originally posted by Nicholas Cheung:

Basically, I mean the very 1st beginning.

As RUP is iternative processes, designing the n+1 phase may be at the same time of coding the n phase. Thus, it will be overlapped.

But the very first beginning, no coding should be done before the 1st draft is released. And the phases should be matched.

Nick

No, sorry, this is not RUP.

In the diagram referenced, phases are shown at top, iterations at bottom.

The goal of the very first iteration, in the inception phase, is to find out wether the project really should be tackled. This one is strong on requirements, but also contains some design and coding - you might need to know wether some high risk techniques really work.

The goal of the second phase is to settle on the architecture, the high level design. Naturally, there is much design going on. But there is also a significant amount of coding, since the only way to tell wether your design really is good is to code it - at least rudimentary.

Another interesting diagram is http://www.agilemodeling.com/essays/iterateToAnotherArtifact.htm - here you see source code being one model of the system, that you use concurrently to other models during development.

[Ko Ko Naing]

Originally posted by Stan James:


I think you're talking about the new "activity diagram". See http://www.agilemodeling.com/essays/umlDiagrams.htm for this one and all the rest.

Definitely yes! They seems a lot like DFDs... I found sthing in the link that you gave above...

In many ways UML activity diagrams are the object-oriented equivalent of flow charts and data flow diagrams (DFDs) from structured development.

I guess UML 2.0 Activity Diagram is the thing that Nick talked about... Or is there sthing else?

Thanks for the link, Stan James...

[Stan James]

Unlike DFD I see no data stores in the list of node types. DFDs still makes sense to me some times when we are considering federations of many systems to get work through the company. We do them in PowerPoint tho

I like swimlanes for some diagrams, too. I first saw those in diagrams of business flows between organizations and roles ... no software in the picture.