FTTH Terminal Box
Field Assembly connector
EPON system
Fiber Switch
SFP Transceiver
Media Converter
PDH Multiplexer
Optical Automatic Protect
PLC Splitter
Optical Circulator
Optical Isolator
Optical Switch
Patch Cord/Connector
Optical Adaptor
Optical Attenuator
Patch Panel
Fiber Optic Closure
In-door Terminal Box
Optical Distribution Frame
FTTH Drop Cable
Optical Cable

¡ôUnified Modeling Language (UML)(2)
The adoption of OO technology triggered the need for tools more sophisticated than flowcharting to describe business processes. Developers needed something that would let them create visual depictions of business processes, similar to blueprints of machinery, that could describe objects and object classes. They also needed a language that nontechnical people could understand, letting them participate more fully in development cycles.
UML was the result of an effort led by Rational Software to merge major modeling techniques. The UML approach(which defines a modeling language, not a programming language) lets systems architects describe classes and methods, and document their relationships.
By offering a common blueprinting language, UML relieves developers of the proprietary ties that are so common in this industry. And because UML uses simple, intuitive notation nonprogrammers can also understand UML models,. In fact, many of the language¡¯s supporters claim that UML¡¯s simplicity is its chief benefit. If developers, customers, and implementers can all understand a UML diagram, they are more likely to agree on the intended functionality, thereby improving their chances of creating an application that truly solves a business problem.
Instead of describing individual steps in the process, UML favors top-view diagrams that let developers hide details and focus on functionality, not generic view of the application and introduce details and complexity later.
For example, in a typical order entry model, you can simply identify an actor (the order administrator) and a business scenario. Because UML has such a rich set of interrelated symbols, it¡¯s easy to accurately describe business processes and development projects. You don¡¯t have to define individual steps in the order management process, meaning you save time and money.
Each of the diagrams used in UML lets you see a business process from a different angle. Business  users, for example, can view use-case diagrams to see the business scenario overview and understand who¡¯s doing what, while developers can use class and object diagrams to get accurate descriptions of how to build those components into their code.
Object and class diagrams depict static ¡°snapshots¡± of the elements within a system ¡®showing objects¡¯ structure, tributes, and relationships to one another. Activity diagrams show the flow of control from one activity to the next, and use-case diagrams illustrate elements outside the system (For example, the internal workings of a new payroll system would be shower in an activity diagram, whereas external actors, such as the mail order department, would appear in a use-case diagram). Equence and collaboration diagrams show interactive processes: You not only see objects and classes, but also the messages that pass between them. Thus, you can simulate passes through your system using a conventional ¡°what if ¡± approach. State diagrams are used for very dynamic objects that receive and send messages frequently. Finally, component and deployment diagrams show the physical view of your system(including executables, libraries, and interfaces)
bc-optics (hk) limited copyright © 2006. all right reserved    design by sendnet.inc