Prev: attn: morty - inspiring movies - geh memco - (1/1)
Next: Object Oriented Completeness
From: Lilly on 19 Feb 2007 11:12
Dear all, we are modeling a "complex" system involving

1- an existing ERP
2- an existing Planning and Budget Systems (PBS)
3- a new Advanced Planning and Budget Planning System (APBS),
that takes input data from 1 and 2 and sends them some Output data ad
well.

New APBS system is a package we just have to buy from supplier,
no real development involved inside our company, except for
interfaces.

So we modeled ERP, PBS and APBS as 3 Packages

I tried the normal way i.e. exposing interfaces but that's not really
useful, I find it better
to depict interface as a Class or Artifact and then draw "uses" lines
among packages.

e.g. the interface that takes data from ERP into PBS is depicted like
this
| PBS | ---uses--> | I_ERP_PBS_interfacename | ----- uses -----> |
ERP |

Also I can't find a nice way to depict
- frequency (or expected volume) of needed interfaces,
- availability of existig ones

Any hint on how to improve the modeling will be greatly appreciated

Thank you !

From: H. S. Lahman on 19 Feb 2007 16:08
Responding to Lilly...

> Dear all, we are modeling a "complex" system involving
>
> 1- an existing ERP
> 2- an existing Planning and Budget Systems (PBS)
> 3- a new Advanced Planning and Budget Planning System (APBS),
> that takes input data from 1 and 2 and sends them some Output data ad
> well.
>
> New APBS system is a package we just have to buy from supplier,
> no real development involved inside our company, except for
> interfaces.
>
> So we modeled ERP, PBS and APBS as 3 Packages

I can buy APBS as a package since it will be third party software. But I
would expect both ERP and PBS to be multiple packages for anything other
than a Ma & Pa business.

BTW, in UML v2.0 they changed things. The <<subsystem>> stereotype is
now derived from Component rather than Package. This was because
Packages were really intended to support configuration management and
version control rather than application partitioning (i.e., they defined
what model elements were relevant to a release rather than defining a
logical unit of the software itself). If you look at the semantics of
<<subsystem>> you will see that it is a much better fit to what you are
describing than Package. Corollary: the Component Diagram is now a
better place to describe application partitioning in the Systems
Engineering sense than the Package Diagram.

> I tried the normal way i.e. exposing interfaces but that's not really
> useful, I find it better
> to depict interface as a Class or Artifact and then draw "uses" lines
> among packages.
>
> e.g. the interface that takes data from ERP into PBS is depicted like
> this
> | PBS | ---uses--> | I_ERP_PBS_interfacename | ----- uses -----> |
> ERP |

This is fairly routine. You can use the Interface model element (aka
lollipop) and associate it with a subsystem just like you would with a
class. In a Component Diagram you can provide associations between the
<client> subsystems and the Interfaces to indicate which interfaces are
paired with which subsystems.

However, the arrows are dependencies, not associations. They should go
directly between the subsystems because they capture the relative level
of abstraction and a client/service view of the flow of requirements.
That really doesn't have anything to do with interfaces. That is, the
communications implicit in interfaces are orthogonal to the logical
dependencies between subsystems.

For example, one might have a low level subsystem for the UI. The rest
of the application defines requirements for it and depends upon it to
communicate with the software user, so the dependency arrows go TO the
UI subsystem. But the UI is very likely to initiate almost all of the
actual communications as the user does things interactively in the UI.
So the UI will be mostly talking to the interfaces of the other
application subsystems rather than the other way around.

> Also I can't find a nice way to depict
> - frequency (or expected volume) of needed interfaces,

You can't. That has nothing to do with the resolution of functional
requirements. At best, it just specifies a nonfunctional requirement and
UML is not a requirements specification notation.

> - availability of existig ones

Presumably any Interface model element you identify will be needed
available to clients in the solution. Remember that the Component and
Package Diagrams are essentially static views of the system. They don't
describe how and when things are used dynamically.



*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl(a)pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info(a)pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



From: Lilly on 20 Feb 2007 08:59
Everything is clear
and so much helpful to me

THANK YOU !
:-)


 | 
Pages: 1
Prev: attn: morty - inspiring movies - geh memco - (1/1)
Next: Object Oriented Completeness