UML in real
UML in practice basing on RUP
- Business Use Case Model (package, use case, activity diagrams) – to represent the interaction between organization and outside world. For example it may describe use case ‘Order a product’ from ‘Customer’ (actor) perspective.
- Business Analysis Model (package, class, activity, interaction, state machine diagrams) - to represent how the business case is realized internally.
- Domain model (class diagrams) – to represent a general concept of a system as a black box.
- business justification (budget versus possible benefits) – the Net Present Value (NPV) may be used in here
- general schedule proposal
- first version of risks register
Then, we go with RUP Elaboration phase and technical details of the vision are specified in Low Level Definition (LLD) package. If HLD is business-driven and it is delivered mainly to take business decisions, LLD is technical-driven and it answers on technical questions. How particular functionalities will be developed? What components are we going to have? Which database will used? Etc..
• Prince2 – “Starting up the Project” and “Initiate the Project”
• PMBoK - initiating and planning processes groups
• MSF – Envisioning and Planning phases
UML in practice basing on EA
Except of three models mentioned above EA offers rich set of model patterns:
Of course there is no need to use them all in each project and this is just the library, from which you may pick up right set of things:
- Business Process Model Pattern – is Business Analysis Model mentioned above
- Requirements Model Pattern – it is a very useful model, which helps you organize the required functionalities especially if there is a big set of them. Privately, when I see the specification where each requirement has its own unique number like FUN_02_03, the one immediately score extra points. The interesting point in here is that a new version of PMBoK (Mr. number 4) contains new processes delivered to support requirements management.
- Use Case Model Pattern – is Business Use Case Model mentioned above
- Domain Model Pattern – is a Domain model mentioned above
- Class Model Pattern – can be used during the work on LLD to specify technical details of the solution. That is especially useful to detect relations and generalizations, especially when you plan to deliver the complex framework and not some standard, typical project. Cool thing about EA is that in resources you may find ready to use design patterns from GoF. EA delivers tools to generate class skeletons in various languages, reengineering tools and even tools to create build scripts. If you are going to document every single class in your code you may draw. This may happen especially if you build your solution over some legacy code. My rule of thumb is that the best approach is to create the class model at the beginning and synchronize it with reality shortly after the delivery to the customer (when waiting for his feedback).
- Database Model Pattern – the same as above, applying it to DB.
- Component Model Pattern – that is a very useful approach to look at physical design from higher level than classes and tables. This thing lies somewhere between HLD and LLD and it is prepared the most often during a planning phase.
- Deployment Model Pattern – that is an opaque for deployment diagrams necessary to specify how the solution will be delivered on hardware
- Testing Model Pattern – that is model useful for QA teams to prepare test cases and scenarios.
- Maintenance Model Pattern – during on going use of the system, maintenance model helps to keep the track about the changes to the original requirements. The model can be supportive to introduce the solution like the Integrated Change Control. Nevertheless the most important is to have on board the Bug Tracking System or more advanced Issue Tracking Systems – the nice comparison can be found in here.
- Project management Model Pattern – EA contains the support for resource allocation, effort management, risks management and metrics like use case metrics. That is not a thing, which will replace the MS Project, Excel or the intranet tools, but in some cases it may be useful.
- User Interface Model Pattern – one of the most difficult things during analysis is the design of GUI. Very often the things are sketched on paper or flip chart. Usually when you create some system for the customer, they already have their customs. They may have previous version of the application or there are used to some other critical application. Very often it is just enough to follow the base line. If you create brand new system and there is no base line, my rule of thumb is to create the mock-up. The quickest way to do it, is to use IDE, which will be used later for development (MS Visual Studio, Eclipse, NetBeans). Then you present it to the customer for the acceptance and development has also the start point. Alternatively the EA offers the model dedicated for these purposes. It is not too sexy and if you want to model some specific controls you may need some time, but it allows to show nicely the flow of user interactions at least.
Even when you have used the UML there is couple of non-obvious tricks, which can be useful in particular situations:
- Class diagrams – there are the following base type of relations between objects, where each of them may be strong (solid line) or light (dashed line):
o Generalization - indicating some abstracts for some of real objects. It is often used because of OOP when abstract class or interfaces are designed. (triangle, empty arrow)
o Aggregation – presenting that an object consists of 0 or many of the other objects. If the child element is deleted when master element is deleted, we speak about strong aggregation (full diamond). If not, then there is a weak aggregation (empty diamond).
o Dependencies – unlike the regular relation, if there is some direction like using or dependency we use the arrowed line. Very often that line contains also some description, which is a stereotype like <
Communication diagrams contains three very nice objects which comes from MVC design pattern
o Control - the Control equivalent
o Entity – the Model equivalent
Activity diagrams contains a number of specific options like: o object flow between two activities
o exception handling and exception regions
o partitioning (splitting the diagram on horizontal or vertical stripes)
Composite diagram specifies:
o Ports which are represented by the named rectangle on a border of component.
o Delegate mechanism which allows to show that particular class is responsible for delivering external service through the interface or port.
o Collaboration, which allow to group set of elements