Paul Newton

Ranch Hand
+ Follow
since Jul 17, 2001
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Paul Newton

Yes - but the Home interface is itself a remote interface. And remote interfaces are part of the RMI framework.
So...you could answer 1,2,3,4 for this question.
paul.
A Component Diagram as defined by UML is not tied to any methodology. UML is simply a notation - it does not imply any process (RUP or otherwise).
UML defines the notion of components separately from classes. I realise that the UML definition is not entirely clear, but the idea is that a component is more oriented towards a module or replacable unit. This is typically a set of classes that together form a discrete part of the system. Try thinking in terms of abstraction - components are more high-level - think BillingComponent, ReportGenerator, SecurityManager, where classes are at a lower-level (Customer, Principal, Role, Account, Report etc).
A component is typically made up of other classes. A component diagram shows how classes relate to components, how components relate to other components, and how components relate to physical artifacts (files etc).
I think the source of your confusion comes from the difference between a component and a class. I have just looked at Cade's book, as this is the one you seem to be using. First of all, I would say that Cade is not necessarily the best book to learn about UML. It is written with a very specific purpose in mind (passing the exam), and its treatment of UML is very brief, and not always that clear.
There are 4 examples of Component Diagrams. I agree that if this is all you have to go on, then the difference between components and classes is not very clear. The SearchController servlet is shown as a component. Isn't this just a class? Well, yes, in this case it is. As UML states - a component can be made up of 1 or more classes.
Components become more interesting when you start building classes together into a single module. Think of an EJB. This typically has a bean implmentation (EnterpriseBean), a generated stub (EJBObject) and a home (EJBHome). There may be some other DAOs and other classes thrown in as well. This group of classes provide a single, coherent purpose - a component. You would show all the EJB classes on a class diagram, while you could show them as a single component on a component diagram (exposing a set of interfaces).
In the Cade example, the Component Diagrams only show dependencies betwen components (SearchController uses SearchEngine). But Component Diagrams can be much more expressive than this - you can show how the classes are packaged into the component (EJBHome, EJBObject, EnterpriseBean etc relating to the EJBComponent). You can show how the components are realised in files (MyBean is implemented in mybean.jar). None of this comes out from the Cade book, so that Component Diagrams start to look more like Class Diagrams. Or lets just say, that the benefits of a Component Diagram in the Cade book are not quite as apparent.
You referred to control and entity classes. These are sterotypes that are proposed in the Rational Unified Process, that came from Jacobson's Objectory work. They are simply sterotypes that can be attached to classes during the early analysis phases. They are useful for analysing Use Cases, and identifying the initial classes. These stereotypes have nothing to do with components in a Component Diagram. However, I can see why this might appear that way in the Cade examples.
Traditionally, I think design literature (and practice) has focused on the class abstractions at the expense of components. In addition, the UML specification has sometimes been criticised for a vague definition of components. With the more widespread use of components models (OLE/COM/DCOM/DNA, EJB, CORBA Component Model etc), this is starting to change.
I hope this helps. The best advice I can give is to take a look at some other UML resources. This will give you a much more rounded view of UML, and how it is used. 'UML Distilled' by Fowler is pretty much a classic. Craig Larman's 'Applying UML and Patterns' is one of the best books I have read concerning modelling and the development process. There are some books that deal more with components (Building Web Applications with UML by Jim Conallen). Look also at the UML spec - I know it is dry reading - but once you get used to the layout, it is invaluable.
Your final point about the exam - do you need to 'understand' or 'guess' the role of a Component diagram? Well - you would be better asking someone who has passed or written the exam. If the Cade book is representative of the exam, then I do not think the level of UML knowledge required is very detailed. The UML chapter in Cade is very brief and does little more than a quick fly-through of the main points.
Hope this helps.
regards,
paul.
The SCEA exam tries to prepare you for being an architect. In this sense, you are expected to know the purpose of specific J2EE technologies and how they are used.
Specifically, you are NOT expected to demonstrate development skills. You do not need to know the API specification or method signatures (compared to say, the SUN Programmer exam).
regards,
paul.
Component diagrams and class diagrams are related, but different artifacts.
First, what is a component? This is an endless question. The UML spec defines it as "...a modular, deployable and replaceable part of a system that encapsulates implementation and exposes a set of interfaces". Okay, maybe not much clearer. But the intention is that a component is a packaging of classes - not usually a single class in itself (although this is possible). A component encapsulates some cohesive piece of functionality. In this way, a component is made up of ('specified' in UML terms) by one or more classifiers (e.g. classes).
To take a crude example, a component might be 'Customer Billing Component' that calculates the movements on a customer account. This component is made up of several classes (e.g. 'Customer', 'Money', 'Account', 'Order' etc).
A component model shows the dependencies between components (ReportPrinter uses CustomerBilling). It shows which classes are used to define a component. It also shows the '...artifacts that implement them' e.g. CustomerBilling is contained inside 'billing.jar'.
You can take UML as far as you like and use adornments to stereotype the dependencies ('reside', 'implement' etc). Although I think the goal of the SUN exam (or at least, judging by the Cade book) is just to understand the purpose of a Component diagram in the development process.
regards,
paul.
[ October 18, 2002: Message edited by: Paul Newton ]
MVC is a design pattern. It can arguably be categorised as a coding pattern (like most of the GoF patterns) or as an architectural pattern. But - MVC is still a pattern. It is not architecture (although it can be used in an architecture).
What is a framework? In my view, 'framework' is a widely over-used word. Whenever someone puts together a few classes, then it is labelled a 'framework'. This is misleading. A framework is intended to be a particular arrangement of classes that define a certain set of interactions with well-defined extension points. A framework is a reusable design of part of a system, that can be used as the basis in new applications. A framework cannot be used as is - it must be extended and integrated into a real application.
Users of a framework instantiate the framework by 'filling in' the missing parts or extending the appropriate classes to achieve an end result. A framework acts as a useful starting point around which to build an application. In this way, a framework will usually define some (implicit or explicit) architecture, by virtue of the assumed interactions.
Struts is a good example of a framework. It defines a set of interactions, and an overall design or form for building Web applications. However, you can only use Struts by extending and instantiating the framework (by writing your own Actions and configuring the runtime XML descriptors). Struts makes use of an MVC pattern, but it is more than that.
A framework makes use of design patterns. Some frameworks make use of a single design pattern to the extent that the difference becomes less clear. This is I think why Struts is often described (even on the site) as MVC.
This is only my take on this. I have seen endless discussions of frameworks - what it is and what it is not. It reminds me of the 'what is a component' discussions. These will never end!
regards,
paul.
P.S Here is an interesting paper on frameworks, and how they can be developed. A 'pattern language' for frameworks...
http://st-www.cs.uiuc.edu/users/droberts/evolve.html
[ October 18, 2002: Message edited by: Paul Newton ]
Most application design or software engineering books will attempt some definition of architecture. The SUN study guide includes 1 from the RUP book, and another from the SUN SunTone methodology. You will find many others in the
literature.
Architecture is not always easy to define, especially in a short 'sound-bite'. I often find it helps to think in terms of levels of abstraction or 'focus'.
Architecture looks at the overall shape and form of the application - how the main parts interact. What are the underlying principles? Common services and components? How are messages passed through the system? How do clients interact with the core system? How is end-to-end security provided? etc.
Architecture is more often concerned with resolving the Non-functional requirements in the context of the overall problem.
Design is concerned more at the detailed implementation level - specific business rules, Use Case implementations etc. e.g. How can I store a CustomerOrder in a particular table? How do I update an Account balance?
Of course, in many cases these differences can blur. Architecture is still a design activity and there will inevitably be overlap - depending on the audience and the point of view (for example, the previous example of storing a CustomerOrder could be viewed as an architectural problem in terms of the wider object-relational mapping issues).
On your final questions - yes, system configurations, networks, servers etc are very much part of an architecture. They are often referred to as System Architecture, Network Architecture, Operational Architecture etc as opposed to Application Architecture (class design, iteration diagrams etc).
A good architect(s) should try consider all of these aspects. For example, a good application architecture should take into account the final system deployment (supported in UML via Deployment Diagrams). These real important for performance and failover strategies. Similarly, network configurations and distribution of components have real impacts on application design (especially when using inherently distributed technologies such as EJB).
regards,
paul.
Jim -
I was interested in this comment. How do you see security of Web Services being different from that of other distributed environments (e.g. CORBA Security Services, EJB Security Framework)? Do you mean from a granularity point of view? as a service-based architecture? or simply from a logistical perspective?
Thanks for any feedback on this.
regards,
paul.
18 years ago
If I understand this article correctly, I think the real point they are making is that COBOL is supported in the .NET environment. Indirectly, this allows you to expose COBOL programs as web services - by virtue of the fact that a .NET program can use any other .NET component. Despite the regular hammering of .NET by the J2EE community - this is actually a pretty cool thing.
However, this is not saying that your entire Web Services architecture is defined in COBOL (XML parser et al) as was implied in some other threads. You still use the .NET framework to handle the services infrastructure part - delegating to COBOL for the service implementation.
Of course, this is a perfectly good way of integrating legacy environments into a WS model. Use the right tool for the job - C++, Java etc for the XML and services infrastructure; COBOL for legacy data access etc. However, there are already a number of alternatives for accessing COBOL programs from OO environments. For example, IBM have an entire connector framework for doing this. J2EE has its connector architecture as well.
So...in principle it should be simple to wrap any COBOL code with a Java decorator, so it can be used in a Web Services. Not necessarily as clean as the .NET solution, and certainly a different philiosophy - but probably just as effective.
I would invite any comments on this. Perhaps someone has a COBOL web service?
regards,
paul.
18 years ago
I found this article a while ago. It explains how SOAP has been adopted/modified to provide the ebXML messaging layer. ebXML seems very interesting to me, although the big problem with EDI standards is getting enough critical mass. SOAP is much more modest in its goals, but in that sense, perhaps of more (immediate) use.
http://www.advisor.com/Articles.nsf/aid/DRUMR12
regards,
paul.

[This message has been edited by Paul Newton (edited October 29, 2001).]
18 years ago
William, Kyle -
Thanks for the feedback. Unfortunately, that gives me 2 different answers
Anyone else care to settle the argument!
I have made a start with SOAP 2.2, and find it very interesting.
A little hard to work through (light on javadoc), but it is proving useful. I will try to follow the Axis project, and consider a jump in the future.
regards,
paul.
18 years ago
Almost all discussions of Use Cases and UC templates eventually lead to Cockburns work. He makes some templates available in various formats on http://www.usecases.org . I usually use a template based around this, but prefer something a bit lighter.
I would emphasise that the real value of use cases is in the boring stuff - the text, the steps, the paragraphs. A template can be useful (especially to remind you of missing information), but it should not be the focus. I would not spend too long working on a template or even a use case model. Start writing the use cases, and get a clear idea of the system you will be building.
regards,
paul.
Simon, Kyle - thanks for the feedback.
I did skim through Conallen's web book while trying to find examples of J2EE web app notations in UML (don't suppose either of you can help?!). I felt it was a little ASP/Microsoft heavy, as well as an obvious Rational focus, so I didn't really dig deeper. It looks like another visit is in order.
thanks again -
regards,
paul.
I am not sure I agree with the idea that someone somehow invented the waterfall process. This is something that has gradually emerged over the history of early computing - borrowing metaphors and practices from other disciplines (most notably engineering).
I too wince at the thought of a detailed 9 month MS Project, where everything is planned out, right down to the last line of code. However, I think it is a little unfair to lay the responsibility squarely are the feet of the managers. Don't forget that entire corporate cultures have grown up around the idea of predictive planning. Budgets are set 1 year in advance. Resources and financing must be fought over. Managers must size their project or risk losing out on the pie.
Some of the criticisms of XP that I have read, identify this as an area of concern. We can admit that projects change and evolve over time - as Beck says, we should embrace change. However, this raises the question - how do we make our managers embrace this change? And their managers? And the CEOs? And the board of directors. For those that are not used to a more adaptive IT world, I think this can be a very difficult leap of faith. I look forward to the "XP...lessons learned" stories.
regards,
paul.
This was one of those tricky questions where the IBM answer is not entirely satisfactory. If we take Larman as a reference, he states quite clearly (2nd Ed, page 82):
Who should be involved in writing UCs?
"Many, including end users and developers..."
However, for the purposes of the mock exam, the answer was C,D.
regards,
paul.