Home ›
Site map
An overview of all content pages (organised in hierarchical zones/books), keywords, image galleries, menus, and RSS feeds.
Blogs
Community blog and recent blog authors at Webel IT Australia "The Elements of the Web".
- All blogs
- webel's blog (22)
Books
Books at Webel IT Australia "The Elements of the Web".
Profile- About Webel IT Australia
- About Dr Darren
- Dr Darren Kelly's full-career Curriculum Vitae
- Career profile
- Record of employment, consultancy, and R & D activities
- IT Consultant: software architect, systems analyst, Enterprise Java web application developer, Drupal CMS web site developer (Phase6) [CURRENT]
- IT Training: OMG Systems Modeling Language (SysML) seminar course preparation, presentation, and specification tracking
- R&D: Electronics patent development employing the Systems Modeling Language (SysML) and 3D modelling
- IT Consultant: software architect, systems analyst, Enterprise Java web application developer, Drupal CMS web site developer (Phase5)
- IT Consultant (OWL/FHIR), National eHealth Transition Authority (NEHTA)
- R&D: Drupal CMS developers web site: http://drupal8info.webel.com.au
- Drupal CMS web site developer and administrator
- IT Consultant: software architect, systems analyst, Enterprise Java web application developer, Drupal CMS web site developer (Phase4)
- IT Training: OMG Systems Modeling Language (SysML) seminar course preparation and specification tracking
- IT Consultant (OCL/UML/MDHT), National eHealth Transition Authority (NEHTA)
- IT Trainer (OCL/UML), National eHealth Transition Authority (NEHTA)
- IT Consultant: software architect, systems analyst, Enterprise Java web application developer, Drupal CMS web site developer (Phase3)
- IT Consultant: Senior Drupal CMS web developer, PHP programmer
- Drupal CMS contributed module development, PHP programming
- IT Consultant: software architect, systems analyst, Enterprise Java web application developer, Drupal CMS web site developer (Phase2)
- IT Consultant: Drupal CMS web site developer, PHP developer, web site administrator
- R&D: Drupal CMS developers web site: http://drupal7demo.webel.com.au
- IT Consultant: software architect, systems analyst, Enterprise Java web application developer, Drupal CMS web site developer (Phase1)
- IT Consultant: software engineer, systems engineer, web developer
- Consultant: Drupal CMS web site development and PHP scripting for systems engineering resources web site for international training organisation
- IT Consultant: Drupal CMS web developer (multilingual site)
- IT Trainer: UML and SysML systems engineering education for the RAAF and DSTO
- Drupal CMS affiliate marketing web site development: The ethical eMarket
- Drupal CMS eCommerce music web site development: play.webel.com.au
- Consultant: Drupal CMS web site migration: www.time2exercise.com.au
- Drupal CMS: composite newsletter development and subscription database engineering
- Consultant: Drupal CMS video web site re-development, extension, and maintenance
- Drupal CMS technical web site development: www.webel.com.au
- R & D: NeXML: a generative XML Schema for the NeXus neutron science data format
- R & D: the Drancing accelerometer real-time music synthesis "air instrument" and Drancel body motion visuals
- OMG's SysML Revision Task Force working group member
- IT Consultant and Trainer: Expert Advisor for Science, Engineering, and Education
- Computational Physicist: Scientific Software Architect
- Visiting research scientist and software architect
- Computational Physicist: Data Analysis Developer
- Object-oriented Java and XML developer, and Unified Modeling Language (UML) architect
- R & D: port-based UML, UML analysis, radio-astronomy synthesis models
- Scientific IT Consultant
- Scientific IT Consultant and UML+Java developer (radioastronomy)
- Research assistant (computer visualisation)
- IT Lecturer
- Research and laboratory assistant, Java programmer, UML analyst
- IT Consultant, dynamic web site developer
- R & D: the Drancing accelerometer music "air instrument"
- Perl Programmer, ISP Technical Support
- C++ programmer, physicist, analyst: development of custom scientific data analysis and visualisation software
- Visiting researcher/inventor (real-time sound synthesis)
- Postdoctoral research scientist, particle accelerator physics (DESY, Hamburg)
- Postdoctoral mathematical assistant (Hilfsmathematiker)
- Postdoctoral researcher, astrophysics
- PhD research student (astrophysics, computational data analysis)
- PhD research student (astrophysics)
- Guest PhD research student (astrophysics)
- Conference assistant and proceedings sub-editor
- Doktorand (PhD astrophysics research student)
- German language student.
- PhD research student (astrophysics)
- University mathematics tutor
- Computational modeling for radioastronomy
- Student vacation employment: C-programmer: digital analysis of Indian paintings
- Student vacation employment: programmer and laboratory assistant
- Qualifications
- Scholarships, grants, and awards
- Computing and information technology skills
- analysis, design, and modelling languages and tools
- animation tools and APIs
- audio and video editing
- audio and video synthesis
- content management systems
- data acquisition and control
- database and persistence technologies
- digital image processing and graphics
- distributed computing
- enterprise architecture
- graphical user interfaces
- markup and data processing languages
- mathematics and engineering tools
- operating systems, graphical desktop and window environments
- programming and scripting languages
- semantic web technologies and languages
- scientific data visualisation tools and APIs
- software development tools
- web and internet technologies
- GlassFish
- [Java Web Services Development Pack (JWSDP)]
- Apache Tomcat
- JavaServer Faces (JSF)
- PrimeFaces
- JavaServer Pages (JSP)
- JavaScript
- Service Oriented Architecture (SOA)
- Web Services Description Language (WSDL)
- PHP (web scripting language)
- Apache HTTP Server
- LAMP
- TWIG web templating language
- Cascading Style Sheets (CSS)
- word processing and office tools
- Organisations
- Avalon Systems (Ultra Electronics Australia)
- National eHealth Transition Authority (NEHTA)
- Deutscher Akademischer Austauschdienst (DAAD) [German Academic Exchange Service]
- GreenSoft Pty Ltd, Australia
- Sitback Solutions
- Technocrat
- ecoSmart Building Pty Ltd
- Project Performance International (PPI)
- Automatisering og Utvikling av Rutiner (AUR)
- Defence Science and Technology Organisation (DSTO)
- Royal Australian Air Force (RAAF)
- Time2exercise
- Unseen TV (online video site)
- Webel Scientific IT Consultancy
- Object Management Group™ (OMG™)
- No Magic Inc. (developers of MagicDraw UML and SysML Plugin)
- ISIS pulsed neutron and muon source, Rutherford Appleton Laboratory
- Institute Laue-Langevin (ILL)
- NeXus International Advisory Committee (NIAC)
- Bragg Institute, Australian Nuclear Science and Technology Organisation (ANSTO)
- Macquarie E-Learning Centre Of Excellence (MELCOE), Macquarie University
- Centre for the Mind, University of Sydney
- Vislab, University of Sydney
- Dot Communications Internet Service Provider (ISP)
- Danish Institute of Electroacoustic Music (DIEM)
- The European Organisation for Nuclear Research (CERN)
- Deutsches Elektronen Synchrotron (DESY)
- International Institute of Business and Information Technology (IIBIT)
- BASF The Chemical Company
- Harvard-Smithsonian Centre for Astrophysics
- Astronomical Society of Australia
- Institute for Theoretical Astrophysics, University of Heidelberg, Germany
- Goethe-Institut Freiburg
- Anglo-Australian Observatory at Siding Springs
- Commonwealth Scientific and Industrial Research Organisation (CSIRO)
- Department of Applied Physics, School of Physics, University of Sydney
- Department of Astrophysics, School of Physics, University of Sydney
- University of Heidelberg (Karls-Ruprecht Universität)
- University of Sydney
- School of Mathematics and Statistics, University of Sydney
- Dubbo South High School
- Publications, Reports, Articles
- An analysis of image formation by MOST (Molonglo Observatory Synthesis radioTelescope)
- Advancements in radiative hydrodynamic simulations of early phases of type II supernovae
- Radiation hydrodynamics of early stages of type II supernovae (PhD thesis)
- Radiation hydrodynamics of early stages of type II supernovae (journal article)
- Type II supernova test cases and breakout modelling with flux-vector splitting and adaptive gridding
- On the conditions for the existence of self-similar solutions of the 1D hydrodynamic equations
- Mathematical modelling of the effect of mating disruption and xenobiotic treatments on the population dynamics of Lobesia botrana
- The role of beneficials in fungicide treatments of Lobesia botrana
- Why is mating disruption of Lobesia botrana ineffective above a particular damage threshold ?
- Mathematical considerations on modelling of emergence and death of Lobesia botrana Schiff.
- Characterisation of Lepton Beam Lifetime Behaviour in HERA
- Many-event lifetime disruption in HERA and DORIS
- The electron beam lifetime problem in HERA
- On symbolic algebra interfaces to numerical initial value problems
- HERA electron beam lifetime machine studies Dec 1995: (I) Analysis of loss monitor data
- HERA electron-beam lifetime disruption machine studies and observations
- Port-based systems engineering of block models for control and simulation of Neutron Beam Instruments of the OPAL research reactor using UML/SysML
- The Instrument Control and Simulation Modelling Language (ICSML) proposal
- The effect of beam excitation on the HERA electron-beam lifetime disruption
- A catalogue of HERA Electron Loss Monitor observations: (I) 08 Dec 1995 - 18 Dec 1995
- A catalogue of HERA Electron Loss Monitor observations: (II) 28 May 1996 - 10 June 1996
- Dust in accelerator vacuum systems
- Comparison of the frequency of beam loss rate increases due to dust particles in HERA under ion-getter pump and NEG operation
- The effect of transverse beam excitation and kicking on the HERA electron beam lifetime disruption
- The effect of a static clearing field on trapped dust particles in the HERA electron ring
- NeXusBeans: object-oriented software components for the NeXus scattering science data format using Java, UML, and XML Schema technologies
- NeXML: automating generation of an XML schema and EMF Java bindings from the XML templates
- Dr Darren Kelly's online résumé: index
- Dr Darren Kelly's model-based software and systems engineering résumé
- Dr Darren Kelly's online Web Technologies résumé
- Service: Drupal-driven Content Management System (CMS) web sites by Webel
- Slideshow of some clients of Webel's Drupal CMS web engineering services
- Client: Project Performance International: Systems Engineering Goldmine site
- Client: Automatisering og Utvikling av Rutiner (AUR), Norway
- Case Study: PLAY music and art project: digital eCommerce with integrated PayPal
- Case Study: Webel IT Australia's Drupal-driven site
- Case Study: Webel IT Australia's Drupal7 demonstration and analysis with object-oriented tutorial module One of Each (OOE)
- Case Study: Webel IT Australia's Drupal8 core and contributed module assessment site
- Case Study: the Ethical eMarket: a marketing site with ethical criteria and product reviews
- Client: Time2Exercise with fitness expert Hadyn Muir
- Community site: German Academic Exchange Service (DAAD) Australia, Research Ambassador and Mentoring Programme (RAMP)
- GreenSoft: GreenDesk product site: web application for environmental tracking of green office buildings
- GreenSoft: company site: developers of the GreenDesk web application and the GreenBase resources portal for green buildings
- GreenSoft: the GreenBase green resources portal for worldwide environmental rating schemes for green buildings, with eCommerce subscriptions
- Client (former): No Magic Inc: the MagicDraw UML & SysML online school
- Client (former): Unseen TV
- Slideshow of some screenshots of Drupal CMS web sites developed by Webel
- Gallery: screenshots of some Drupal CMS web sites developed by Webel
- Why choose Webel IT Australia for your Drupal Content Management System (CMS) web site ?
- Slideshow of some clients of Webel's Drupal CMS web engineering services
- Service: UML-driven Java and XML software engineering services
- Service: IT Training: Unified Modeling Language (UML), Systems Modeling Language (SysML), and UML-driven Java
- Service: UML-driven Software Applications Architecture, Solutions Architecture and Systems Architecture
- Service: UML Parsing Analysis of technical documents and digital texts into graphical UML models
- Service: professional Video, Audio, and Screencasting presentations
- Final Cut video and audio editing and production
- Audio engineering tips
- A review and some remarks on lossless and lossy sound formats, audio codecs, and trends (fashions)
- A summary of a review of music levels for broadcasting, personal use, recording and mastering, including the new LOUDNESS measures
- Audacity: miscellaneous tips
- Audio engineering test/sample file resources, and online generators and online audio tests
- Audio engineering: minimal audible sound levels
- Audio engineering: miscellaneous references
- FFmpeg: command line and GUI audio/video conversion tool: audio references
- Mac OS X: EBU R128 compliant loudness meters and batch processing
- Mac OS X: HOWTO adjust your system's sound quality, and record or find "high definition" audio sources
- Mac OS X: audio engineering plugins
- Mac OS X: some audio engineering apps and tools
- "I paid peanuts and I got monkeys; what should I do now ?"
- Advanced UML and SysML training seminars and workshops
- Course: Practical systems engineering with the OMG's Systems Modeling Language™ (SysML™) and the SysML Plugin for MagicDraw™
- About SysML, MagicDraw's SysML Plugin, and this course
- About UML Parsing Analysis and SysML Parsing Analysis for document-driven systems engineering
- People who could benefit from this course:
- Engineers and Technicians developing complex electrical, mechanical, optical, acoustic, radar, and mechatronic systems requiring graphical systems engineering tool support.
- Logistics and Acquisition Managers interested in graphical tracking of systems elements.
- Requirements Analysts, Systems Analysts, Constraints Analysts, and Systems Architects interested in integrated systems engineering tool support and graphical engineering.
- Scientists interested in graphical associative analysis, modelling, and simulation of systems such as scientific beam instruments, complex natural systems, and taxonomies.
- Technical Project Managers interested in highly traceable systems engineering and strongly process-driven development for wide range of existing development methodologies.
- Day 1 | Overview of UML2 and SysML for systems engineering | MagicDraw UML and the MD SysML Plugin |
- Overview of UML2+ and SysML1+ for systems engineering
- Why graphical, associative, port-based, and patch-based "synthesis engineering" is (potentially) so powerful.
- What UML is and how and why it has been traditionally used “just” for software engineering.
- What SysML is and why you should consider it for your systems engineering projects.
- Anatomy of the SysML Block element
- Overview of the SysML Diagrams (and the UML Diagrams they are adapted from).
- Some example systems used in this course:
- Example: the SysML specification's Hybrid Sports Utility Vehicle (HSUV)
- Example: port-based engineering example: a modular home entertainment system
- Example: signal processing: the Drancing real-time synthesis accelerometer music system.
- Example: MagicDraw UML and MD SysML: the MagicCastle system.
- Example: the participants' own domain-specific workshop case study.
- Aspects of UML2 useful for systems engineering, and how SysML builds on them
- Ownership of Elements: Packages, Models, and Components as Namespaces.
- UML Classes, UML Properties, and Class Diagrams.
- UML Ports, Connectors, and the EncapulatedClassifier
- The UML Interface as Operations and/or data contract: not only for software systems.
- The UML2 “ball and socket” notation: providing/requiring Interface contracts via Ports
- Architectural “Dependency wiring” of Interface contracts in MagicDraw UML
- Structure compartments in MagicDraw UML Class Diagrams and "hybrid" diagrams
- UML2 Composite Structure diagrams
- UML InformationFlows for conveying information.
- UML DataTypes as conveyed data tokens
- Power features of MagicDraw UML and the MD SysML Plugin
- UML2 (and the UML specifications) vs. MagicDraw UML vs. MD SysML
- The UML2 Metamodel, the UML specification, and how to (not) read it.
- The UML2 Metamodel in MagicDraw UML specification dialogs.
- The UML2 Metaclasses in MagicDraw UML (and what they are not).
- UML2 Comments: a real and very useful Element (that is stored in the project "repository") !
- UML2 Artifacts: very useful for systems engineering, but NOT formally in SysML.
- UML2 Components: very useful for systems engineering, but NOT formally in SysML.
- UML2 Constraints: defining them, representing them
- UML2 InstanceSpecifications and value Slots: representing value states of systems
- Overview of UML2+ and SysML1+ for systems engineering
- Day 2 | SysML: history, specification, metamodel | structure, flow, quantity, value, configuration, context, time, space |
- Overview of the SysML specification and the OMG's revision process
- The SysML diagrams, elements, profiles, stereotypes, and notations
- Representing structure: the SysML Block, Ports, Connectors
- The SysML Block: an extension of the UML Class
- SysML "block properties"
- Understanding system context in SysML
- SysML Port and FlowPort
- The SysML Standard Port
- Example: block compartment display of Ports
- Representing flows: the SysML FlowPort, FlowSpecification, and ItemFlow
- MD SysML supports "nested" ports !
- Consider using "nested" Ports for separation of physical plug/socket contract from signal protocol
- Example: Object Monitor: Combining standard Ports and SysML FlowPorts: building blocks and Ports as BDD
- Example: SysML spec Water Spigot problem reworked to use "nested" Ports instead of SysML FlowSpecfiications.
- Example: nested Ports: HiFi "producer" and "consumer"
- Representing physical, industrial, and financial quantities in SysML
- Representing value state and modes of complex systems in SysML
- Mathematical Constraints analysis in SysML
- Day 3 | Behavior, State, Requirements, Allocation | Process Management, Project Management, Human Management |
- Modelling Behavior and State in SysML
- Use Cases in SysML
- Using SysML Requirements
- The normative SysML Requirement
- The very useful non-normative SysML requirement extensions
- Deriving one Requirement from another with SysML DerivedReqt
- Refining descriptions of Requirements with other element types using SysML Refine
- The SysML Satisfy relationship: tracing fulfillment of Requirements
- The SysML Verify relationship, TestCase, and VerdictKind
- [Non-standard] on applying the SysML «requirement» Stereotype to UML2 Components.
- HOWTO elicit SysML Requirements and how to relate them to other elements.
- HOWTO callout SysML requirements metadata into UML notes in MagicDraw UML
- HOWTO use hyperlinks and related elements in MagicDraw to trace between source
- Allocation in SysML
- Using SysML for Project Management
- Day 4 | SysML review, MD SysML tips, fun examples, questions | The UML- and SysML Parsing analysis recipes |
- More TIPS for using SysML in MD SysML
- Exploit the powerful hyperlinking and diagram icon facilities of MagicDraw for easy cross-navigation between elements, packages, models and diagrams
- Really very tricky MagicDraw UML tricks
- TIP: Use a BlockPackage or BlockModel to group a Block and supporting elements
- On combining UML and SysML to get the best of both worlds in SysML tools
- SysML Review and Question time
- The UML- and SysML Parsing Analysis recipes for sentence-by-sentence systems engineering
- From engineering documents in natural language to understandable SysML models.
- To make the recipe work you need the UML2 Component (not officially in SysML)
- The SysML Parsing Analysis recipe (currently) works best in the MagicDraw UML and MD SysML tools.
- The UML2 Component as logical and graphical «wrapper»
- Ownership and the UML2 Component
- HOWTO nest «wrapper» Components to reflect source text paragraph structure
- Hyperlinked “focus diagrams” for «wrapper» Components
- HOWTO trace participation in logical «wrapper» Components: "unwrapping"
- HOWTO separate parsing analysis elements and «source» text «wrapper» Components in Models from systems elements in Packages
- More TIPS for using SysML in MD SysML
- Day 5 | Workshops | SysML Parsing Analysis of your own technical document into SysML models | Team presentations, group discussion |
- Workshop | morning | SysML Parsing Analysis of a document of your choice in MD SysML |
- Participants will spend the morning working through an engineering document of their choice, extracting SysML model elements using sentence-by-sentence parsing analysis.
- Participants are encouraged to model from their own team, role, and domain perspectives
- The presenter will offer assistance throughout on modelling and tool features.
- There will be the opportunity for freestyle diagramming to prepare a presentation of results.
- Workshop | afternoon | team presentations followed by discussions of each team's SysML models | conclusion |
- Workshop | morning | SysML Parsing Analysis of a document of your choice in MD SysML |
- Gallery: props used at Webel seminars for UML, SysML, Java, XML and software development process
- 004. coloured sticker notes (can indicate value, team ownership, and direction)
- 039. coloured sticker notes (can indicate value, team ownership, and direction)
- 081. set of coloured pens as instances of the Pen class (match each Team's colour)
- 089. coloured paper clips as instances of PaperClip class (good for marking value state)
- 094. white and grey mice as binary states of the Mouse actor
- 098. playful toy pegs used as Actors (can be easily clipped onto other model elements)
- 113: set of plastic lotus flowers with subtle variation as instances of the LotusFlower class
- 127. a set of coloured plastic balls as instances of the Ball class
- 138. coloured strings: used as Relationships (Dependency, Association, Connectors) for each team
- 141. coloured team labels (instances of the TeamLabel class)
- 156. Exploring composite structure and states of properties with context containers and coloured instances
- 174. the blue team's BlueFactory basket (records the history of product creation in AbstractFactory pattern lessons)
- 180. the pink team's PinkFactory basket, with pink Boxes as containers and the team's ContextMat (records the history of product creation in AbstractFactory pattern lessons, and SysML value state)
- Exploring composite structure and state of properties with context containers and coloured instances
- Overview of Webel seminar props, with coloured team mats, containers, and a variety of classes and objects
- Some past Webel UML & SysML training courses
- Practical systems engineering with the OMG's SysML systems engineering language and MagicDraw's SysML Plugin: a hands-on Webel IT course and workshop held over 5-days
- Introduction to port-based systems engineering with MagicDraw UML
- Introduction to systems engineering with the MagicDraw SysML Plugin
- Java software development patterns in MagicDraw UML (corporate retreat)
- Managing software development process with Plone CMS, JIRA issue tracking, and MagicDraw UML
- UML-driven Java software development with MagicDraw UML
- Tutorial: SysML study case: examination of SysML structure, sysml properties, value type, and value state using coloured props
- ColoredThing.bdd: giving things some value
- ColoredThing.ibd: seeing value inside things
- Ball.bdd: quantities with units in SysML (Version 1.1 style)
- Box.bdd: composition
- Box.ibd: part property and value property symbols
- SmallBox.bdd: a concrete box with a redefined fixed length and the ability to contain 1 ColoredThing
- SmallBallBox.bdd: redefining properties to reflect system constraints and to carry default construction values
- SmallBallBox.ibd: the UML Property.defaultValue as an overriding set of values
- MediumBox (BDD): slightly larger than a SmallBox
- MediumBoxWithSmallBallBox (BDD): a container with deep nesting
- Abstract exploration of initial values
- MediumBoxWithSmallBallBox (IBD): a container with deep nesting
- PsychoMediumBoxWithSmallBallBox (BDD): progressive redefinition to represent deep value state
- PsychoMediumBoxWithSmallBallBox (IBD): the initial values compartment
- Course: Practical systems engineering with the OMG's Systems Modeling Language™ (SysML™) and the SysML Plugin for MagicDraw™
- The Drancing accelerometer music "air instrument"
- Drancing with Wiimotes via wireless Bluetooth (since 2008)
- Gallery: Videos of Drancing air music with Wii Remotes as wireless accelerometers (2008)
- Video: YouTube: Drancing accelerometer music with Wiimotes: 3D variable frequency oscillators + amplitude variation + triggered "air drum" samples
- Video: YouTube: Drancing accelerometer music with Wiimotes: 3D amplitude (volume) variation + triggered "air drum" samples
- Video: YouTube: Drancing accelerometer music with Wiimotes: 3D variable frequency oscillators + triggered "air drum" samples
- DarwiinRemoteOSC accelerometer signal plots
- Gallery: Videos of Drancing air music with Wii Remotes as wireless accelerometers (2008)
- The original Drancing accelerometer suit (since 1997)
- Photo of the original Drancing accelerometer suit
- A triaxial accelerometer as used in the original Drancing sensor suit
- Gallery: Video snippets of the original Drancing accelerometer "air music" sensor suit (from 2002)
- Video: Drancing suit 2002: triaxial accelerometer sound axes: variable frequency and variable amplitude modes
- Video: Drancing suit 2002: variable frequency + variable amplitude mode
- Video: Drancing suit 2002: amplitude (volume) variation of the notes of a triad chord
- Video: Drancing suit 2002: Drumming-by-Dancing "air drums" sample triggering mode
- Video: Drancing suit 2002: "air DJ" scratching: variable frequency + variable amplitude
- Video: Drancing suit 2002: hi-energy sporty: variable frequency + variable amplitude
- Recording note: the video is lo-res webcam, and the audio is subject to poor signal-to-noise.
- Gallery: Images of the original Drancing accelerometer music sensor suit
- Drancing suit 2002: 5 accelerometer "body star" pattern
- Drancing "The amazing musical motion sensing suit"
- Previously data transmission was via cable with plug and socket connection between a DAQ card and the Drancing sensor suit
- Alternative strategies for concealing cables in the Drancing accelerometer suit
- The vision: a Drancer with wireless data telemetry of accelerometer signals
- DranceWare: software for Drancing
- DranceWare: PureData/GEM: real-time music and visuals generation for the Drancing accelerometer music system (2008+)
- Gallery: DranceWare PureData music synthesis patches
- Drancing.pd
- DranceWare.pd
- Drancel.pd
- WiiOSC.pd
- Condition.pd
- GlobalScale.pd
- VFOacc3D.pd
- VFO.pd
- GlobalVFO.pd
- AMacc3D.pd
- GlobalAM.pd
- Drums.pd
- DrumTrig.pd
- DrumSamples.pd
- PlaySample.pd
- GlobalTrig.pd.2
- MonoToStereoPanned.pd
- StereoOutput.pd
- StereoEcho.pd
- Filters.pd
- FilterCh.pd
- Meters.pd.2
- Compressor.pd
- Record.pd
- Global.pd
- DSP.pd
- AccWavetable2x3.pd
- Gallery: PureData/GEM accelerometer visuals and GEM patches
- SysML mockup of PureData DranceWare for Wii remote
- Drancing: PureData/GEM prototype for Wii Remote: downloads and HOWTO for Mac OS-X
- Obtain 2 Wii Remotes
- Download and install DarwiinRemoteOSC and test your Wiimotes
- Download and install PD-extended (PureData audio synthesis software including GEM video synthesis)
- Download and install the DranceWare PureData/GEM prototype for Wiimote on Mac OS-X
- Calibration and homing: a crucial step before you "Drance"
- "Ready, RESET, Drance !"
- Switch on the GEM visual accelerometer monitors
- Some TIPS for getting the most out of DranceWare for Wiimotes
- Gallery: DranceWare PureData music synthesis patches
- DranceWare JSyn real-time audio synthesis (2002+)
- DranceWare with JSyn audio synthesis: multi-column treetable parameter control GUI
- Gallery: DranceWare port-based UML signal processing diagrams (2005)
- _UML2 signal processing models
- Top level UML Composite Structure Diagram of Drancing and DranceWare JSyn
- A simplified representation of a triaxial accelerometer (vector acceleration sensor)
- A representation of the 5 triaxial accelerometers used by Drancing as a subsystem (component)
- DAQcard
- DAQSource
- A composite JSyn software component that performs real-time audio synthesis with AM or VFO
- Sample Triggering in JSyn
- Drancing JSyn UML: Overview
- DranceWare Java visuals (2001+)
- DranceWare Java accelerometer monitor
- DranceWare: Java3D: "body star" accelerometer suit interaction animation
- DranceWare: Java3D: accelerometer interaction demo (snapshot)
- Drancing Java visuals base in UML
- DranceWare: Java: UML of simple accelerometer sensor monitor
- Drancing_swing.uml
- UML of DranceWare Java accelerometer monitor
- Drancing_java3d.uml
- DranceWare: Java3D: UML: accelerometer interaction demo
- DranceWare Java MIDI (2000-2002)
- DranceWare C++ MIDI (1999-2000)
- DranceWare C MIDI (1996-1998)
- Gallery: DranceWare Java software GUIs and UML designs
- Gallery: DranceWare computer visuals and animations
- DranceWare: PureData/GEM: real-time music and visuals generation for the Drancing accelerometer music system (2008+)
- The Drancel: a 3D-accelerometer sound and light "atom" for the Drancing system
- Gallery: the Drancel RGB triaxial accelerometer light and sound "atom"
- Drancel Chromesthesia III: Morpheus mind (Body motion light synthesis) [SILENT]
- Drancel Chromesthesia II: Planet Morpheus (Body motion light synthesis) [SILENT]
- Snapshot of a video of a Drancel RGB accelerometer-driven LED light show
- Drancel Chromesthesia I: Apollo’s vision (Body motion light synthesis) [SILENT]
- "Drancel Planetscapes" accelerometer art
- "Planet Drancel" accelerometer art
- Drancel RGB LED accelerometer light show: mini video 5
- Drancel RGB LED accelerometer light show: mini video 6
- Drancel RGB LED accelerometer light show: mini video 7
- Drancel RGB LED accelerometer light show: mini video: 4
- Drancel RGB LED accelerometer light show: mini video 8
- Drancel RGB LED accelerometer light show: mini video 1
- The RGB LEDs of a Drancel
- UML diagram of a Drancel LED RGB accelerometer light show unit
- Drancel RGB model as nested UML instances
- Drancel RGB LED accelerometer light show: mini video: 3
- Drancel RGB accelerometer LED lights prototype (2005, OBSOLETE)
- Mini videos from a Drancel RGB LED light show
- Gallery: 3D Drancel RGB visuals and sound synthesis with a PureData/GEM Prototype of DranceWare (images and videos, from 2010)
- 1 Drancer (acceleration avatar): view from behind, projected onto screen
- 1 Drancer (acceleration avatar): view from behind, projected onto screen: colour synthesis
- 2 Drancers (acceleration avatars) each with 5 Drancels
- 2 Drancers (acceleration avatars) each with 5 Drancels: arbitrary separation between units and centroids, in 3D
- 2 Drancers (acceleration avatars) each with 5 Drancels: arbitrary separation between units and centroids, in 3D: from front at distance
- 2 Drancers (acceleration avatars) each with 5 Drancels: arbitrary separation between units and centroids, in 3D: from front/side at distance
- 2 Drancers (acceleration avatars) each with 5 Drancels: synthesised light projects on screen
- 2 Drancers (acceleration avatars) each with 5 Drancels: synthesised light projects onto screen
- 2 Drancers (acceleration avatars) each with 5 Drancels: synthesised light projects onto screen
- 2 Drancers (acceleration avatars) each with 5 Drancels: view from front
- 2 Drancers (acceleration avatars) each with 5 Drancels: with 1 Drancel offset
- 3 Drancers (acceleration avatars) with 5 Drancels each: like RGB pixels when viewed from a distance
- 3 Drancers (acceleration avatars) with 5 Drancels each: with very large Drancel size w.r.t. Drancer spacing
- A hemispherical Drancel RGB in a spherical cage
- A hemispherical Drancel RGB in a spherical cage: view from above
- A single 3D Drancel with orthogonal RGB "light horns"
- Drancel RGB LED reflector principle
- Drancer (acceleration avatar) with 5 Drancels: when viewed from a distance act like RGB pixels
- PureData/GEM audio and visuals synthesis patch for demo of 2 Drancers with 5 Drancers each: top-level of rapid prototype
- Video: 1 Drancer (acceleration avatar) with 5 Drancel RGB virtual triaxial accelerometers: colour=sound synthesis principle in 3D (PureData/GEM) 3 VFOs per Drancel and simulated sinusoidal signals
- Video: 2 Drancel RGB acceleration synthesis atoms: Drancing colour=sound synthesis principle in 3D (with 3 VFOs driven by simulated sinusoidal signals)
- Video: 2 Drancel RGB acceleration synthesis atoms: Drancing colour=sound synthesis principle in 3D (with 3 VFOs each driven by Nintendo Wiimotes)
- Video: 2 Drancers (acceleration avatars) each with 5 Drancel RGB virtual triaxial accelerometers: Drancing colour=sound synthesis principle in 3D (with 3 VFOs and simulated sinusoidal signals)
- Video: 2 Drancers (acceleration avatars) each with 5 Drancels: in PureData/GEM Prototype of DranceWare: Driven by Wiimote
- Video: 2 Drancers (acceleration avatars) each with 5 Drancels: in PureData/GEM Prototype of DranceWare: rotating camera: driven by Wiimote
- Video: Drancel RGB accelerometer "light horns" sound=colour synthesis principle (with 3 Variable Frequency Oscillators): driven by Wiimote
- Video: The Drancel RGB triaxial accelerometer colour=sound synthesis principle (with 3 Variable Frequency Oscillators): driven by Wiimote
- Video: The Drancel RGB virtual triaxial accelerometer: colour=sound synthesis principle in 3D (with 3 VFOs and simulated sinusoidal signals)
- Gallery: the Drancel RGB triaxial accelerometer light and sound "atom"
- Did you know ? About the Drancing accelerometer music system
- What is Drancing ?
- Drancing uses real-time synthesis of sound and visuals
- Drancing is acceleration-centric because acceleration is independent of a fixed reference system !
- Cable-based approaches have been rendered obsolete by modern wireless data telemetry (such as Bluetooth from the Wiimote).
- Drancing does not really care whether you use a Wii Remote or another source of accelerometer signals, it encapsulates any triaxial accelerometer as a conditioned "Drancel".
- I stop short of playing loops to establish a timebase, as it does NOT promote virtuosity in gestural music.
- I will probably migrate soon to completely synthetic (real-time generated) drums, instead of using triggered drum samples.
- Note: because the frequencies achievable by body movement are very low compared with audible oscillator frequencies it is not possible to demonstrate true frequency modulation (FM) with the variable frequency oscillator (VFO) mode.
- Terminology: "Drancing" actually refers to the entire accelerometer music system, including hardware; "DranceWare" refers to the audio and video synthesis software components, and a "Drancel" is a virtual encapsulation of a triaxial accelerometer.
- The 1st Drancing prototype from 1997 used MIDI triggered samples, including theatrical samples like bird noises, ringing telephones, and gun shots recordings !
- The audio in the video snippets of Drancing accelerometer music and visuals with Wii remotes was in fact recorded from system audio by a screencast capture system so that the modes and settings were also recorded visually simultaneously.
- The original Drancing sensor suit used 5 triaxial accelerometers in a "body star" pattern"
- This is the "Drumming-by-Dancing" air drums mode after which Drancing was originally named in 1997.
- Applications of Drancing
- History of the development of the Drancing "air music" instrument
- In the press: "Drancing past the keyboard"
- Galleries index: Drancing images and videos
- Drancing: overview of all videos involving the Drancing accelerometer music system and the Drancel RGB sound and light synthesis atom
- Terminology: A Drancer is an "acceleration avatar" of the Drancing accelerometer music and visuals system
- Drancing with Wiimotes via wireless Bluetooth (since 2008)
- NeXML: a generative XML Schema with EMF Java bindings for the NeXus format
- Instrument ModelServer
- Drupal CMS technology zone
- UML zone
- Galleries meta-index: overview of all UML and SysML gallery groups
- UML Parsing Analysis zone
- Galleries index: UML Parsing Analysis examples
- Tutorial: the UML Parsing Analysis recipe(s)
- "0th order" UML Parsing Analysis: source text in UML text boxes as cosmetic "parsing container", no Relationships.
- "1st order" UML Parsing Analysis: stereotyped Comment as a simple source text container related to UML model elements by "handles"
- "2nd Order" UML Parsing Analysis: use a «wrapper» Component as a container for the source text, and relate it to model elements using a Relationship
- External: MagicDraw UML eSchool: UML Parsing Analysis tutorial trail
- Examples
- Gallery: UML Parsing Analysis demonstration: Wikipedia Shapes (from 2009)
- 'Shape is all the geometrical information that remains when location, scale and rotational effects are filtered out from an object.'
- A shape whose points belong all [in] the same plane is called a plane figure..jpg
- In geometry a polygon .. is traditionally a plane figure that is bounded by a closed path or circuit, composed of a finite sequence of straight line segments (i.e., by a closed polygonal chain)
- These segments are called its edges or sides, and the points where two edges meet are the polygon's vertices or corners.
- A diagonal can refer to a line joining two nonconsecutive vertices of a polygon or polyhedron
- A regular polygon is a polygon which is equiangular (all angles are equal in measure) and equilateral (all sides have the same length).
- An equilateral polygon is a polygon which has all sides of the same length.
- A triangle is one of the basic shapes of geometry_ a polygon with three corners or vertices and three sides or edges which are line segments
- A quadrilateral is a polygon with four 'sides' or edges and four vertices or corners.
- In mathematics, a locus (Latin for place, plural loci) is a collection of points which share a property
- In mathematics, a conic section (or just conic) is a curve obtained by intersecting a cone (more precisely, a circular conical surface) with a plane.
- UML Parsing Analysis: notes and reusable policies
- TIP: the full benefit of UML Parsing Analysis can only be obtained through the physical and cognitive act of analysis and interpretation of text as an associative, graphical, UML model, not in just studying someone else's UML interpretation.
- The term 'UML Parsing Analysis' is not a trademark or an official OMG technology (whereas 'UML' is an OMG trademark).
- UML Parsing Analysis: 0th order: free text containers, no traceable relationship or binding between UML model elements and "parsed" source text, visual association only.
- UML Parsing Analysis: 1st Order: "physical" containment (ownership) of Comment by Package, Model, or Component.
- UML Parsing Analysis: 1st Order: uses Comments containing source text snippets with loose handle binding to UML analysis elements.
- UML Parsing Analysis: 2nd Order: DirectedRelationship (Dependency, Realization, ComponentRealization, Generalization) used to carry parsed text source snippet.
- UML Parsing Analysis: 2nd Order: «wrapper» Component used as (relatable) container for «source» text.
- UML Parsing Analysis: Each source text "wrapper" Component is hyperlinked to at least a dedicated "focus" class diagram, and possibly also to other UML diagram types.
- UML Parsing Analysis: InstanceSpecifications in "object diagrams" used to illustrate interpretation and/or understanding of «source» text.
- UML Parsing Analysis: STUB(S) ONLY, INCOMPLETE (NOT STABLE OR CONVERGED) !
- UML Parsing Analysis: [subject, predicate, object] represented here by an Association with "directional" name (only) between Classes.
- UML Parsing Analysis: example: note use of «stereotype» to indicate container of «editorial» text annotation.
- UML Parsing Analysis: example: note use of «stereotype» to indicate container of «source» text snippet.
- UML Parsing Analysis: example: there is more than one «source» of parsed and analysed text snippets indicated by different stereotypes.
- UML Parsing Analysis: no explicit binding of model elements to source text is shown.
- UML Parsing Analysis: old example, does not have clear binding of UML analysis elements to a "relatable parsing container" element with source text.
- UML Parsing Analysis: prefer indicate «editorial» remark with a «stereotype», to distinguish it from the «source» text; additionally also use a style (like italic font or background color) bound to the «stereotype».
- UML Parsing Analysis: prefer use a «stereotype» to indicate the parsed and analysed «source» text.
- UML Parsing Analysis: prefer use only one sentence of source text per "parsing container" ! Motto: "divide and conquer" !
- UML Parsing Analysis: the container Element of every «source» text snippet and «editorial» remark should be clearly stereotyped in the model, even if that «stereotype» is not displayed in every diagram !
- UML: MagicDraw UML: the "parasitic" «wrapper» Component strategy (whereby a "logical" Component does not "steal" ownership of a graphically contained element) is known to work in at least MagicDraw UML; it may not work in all UML2 tools.
- Gallery: UML Parsing Analysis: miscellaneous examples and supplementary diagrams
- UML tools zone
- MagicDraw UML zone
- Galleries index: Webel's contribution to the MagicDraw UML and SysML online eSchool
- Gallery: HOWTO easily assign multiple diagram hyperlinks and GoTo to a chosen one in MagicDraw UML (external)
- Gallery: HOWTO reverse-engineer existing Java source into MagicDraw UML
- Gallery: HOWTO use a UML2 Component as a graphical and/or logical «wrapper»
- Gallery: HOWTO use the active validation engine to apply fixes in the MD SysML Plugin
- Gallery: HOWTO: provide/require Interfaces via Ports for service orientation in MagicDraw UML: Quick Start Guide (2008)
- Gallery: MagicDraw SysML Plugin (MagicDraw UML eSchool, from 2007-2008)
- Gallery: HOWTO inherit structure in MagicDraw UML and MD SysML
- Gallery: HOWTO: Activity Decomposition in MD SysML
- Gallery: HOWTO: manage block structure and assign values with MD SysML (from Mar 2008)
- Gallery: Overview of the SysML diagrams in MD SysML (from 2008)
- Gallery: SysML Parsing Analysis: The Hybrid Sports Utility Vehicle (SUV) sample problem in MD SysML (from 2007-2008)
- Gallery: SysML profile/metamodel and additional MagicDraw SysML stereotypes (from 2008)
- Gallery: SysML1.0 issues (2007-2008)
- Gallery: Magicdraw eSchool Frequently Asked Questions (FAQs) about modelling (from 2007-2008)
- Gallery: OMG SysML RTF: proposal by D. Kelly for unified "value slice" system for initialisation, configuration, and animation (from 2008)
- Gallery: OMG SysML RTF: proposal by Darren Kelly for Quantity profile/metamodel [WORK IN PROGRESS] (from 2008)
- Gallery: Tutorial: Port-based reverse-engineering and Java, in MagicDraw UML (from 2008)
- Gallery: Tutorial: The UML Parsing Analysis recipe (MagicDraw UML version, from 2007)
- Gallery: Tutorial: principles of port-based software and systems engineering (MagicDraw UML eSchool version, 2008)
- Gallery: UML style tips (MagicDraw UML eSchool version, 2007)
- Gallery: UML2 metaclass examples (MagicDraw UML eSchool versions, 2007-2008)
- Gallery: reverse and analysis of the unitsml.nist.gov XML Schema in MagicDraw UML15.0
- Video screencast: YouTube: MagicDraw UML: SysML Plugin active validation tutorial
- Notes
- Deep nesting of Property symbols in structure compartments and composite structure diagrams is permitted in some UML tools, and formally supported in SysML Internal Block Diagrams.
- MagicDraw UML permits display of InstanceSpecifications on Composite Structure Diagrams (and SysML Internal Block Diagrams)
- UML note: OBSOLETE: pre UML2 !
- UML note: from old version of MagicDraw UML, pre-UML2, no InformationFlows, no true Composite Structure, no Ports.
- UML note: these diagrams from 2005 contain workarounds for some limitations in UML2 composite structure support in an earlier version MD 10 EAP Beta2 of MagicDraw UML.
- UML2 note: this OBSOLETE trick of pseudo-nesting of Component classifiers was a workaround for older versions of MagicDraw UML; since 2007 MagicDraw UML correctly supports deep nesting of composite structures with parts and ports.
- UML2.1.2: contains content quoted from the OMG UML specification documents for educational purposes.
- UML2: this diagram does NOT show connected "instances", it only shows "Dependency wiring" of proivided/required Interface contracts, i.e., where valid connections may be made when these EncapsulatedClassifiers are used in a higher context !
- UML: consider using InformationFlow for data token types and to indicate direction on Association/Connector.
- Galleries index: Webel's contribution to the MagicDraw UML and SysML online eSchool
- MagicDraw UML zone
- UML: notes
- In MagicDraw UML, classifier-level sterotypes "show through" on symbols of instance level properties, unless that property has a visible (non-hidden) instance-level stereotype applied.
- UML1.x: OBSOLETE !
- UML: MagicDraw UML: OBSOLETE: the use of a additional Component wrapping a Class with composite structure to contain related notes is a workaround for a BUG in a former version of MagicDraw UML.
- UML: custom stereotype images have been used to extend UML element symbols.
- UML: parasitic "wrapper" Components have been used in MagicDraw UML to logically group Class & Interface elements.
- UML: style: Classifier name written "French style" with qualifiers after main noun (as in 'vin rouge').
- Galleries index: some miscellaneous (and curious) UML galleries
- Tutorial: some UML modelling and diagramming tips, tricks, and best practices
- Tips for all UML diagram types
- UML: TIP: show the diagram info box with creation and modification timestamp and author (unless you have a very good reason not to).
- UML: TIP: as far as possible ensure you can navigate your entire model from every diagram to related diagrams using the symbol and/or hyperlink facilities (and/or "navigate to usages" facility).
- UML: TIP: use oblique paths until your diagram is stable, and only use rectangular paths once you are sure the system is stable.
- UML: TIP: use bezier lines rarely and with caution, as they are subject to graphical hysterisis.
- UML: TIP: experiment with heuristic layout algorithms.
- UML: TIP: WARNING: showing the symbol of a client Element or usage context in a diagram featuring a supplier Element can block modularisation of that supplier's Package or Model !
- UML: TIPS: Analysis vs. Design: how to organise your UML models
- UML: TIP: ALTERNATIVE: prefix each *Analysis Package with an asterix '*'
- UML: TIP: DO NOT refer to "analysis" Elements from "design" Packages (or from "design" diagrams) !
- UML: TIP: always use a Model (not a Package) for analysis elements and analysis diagrams (that may refer to design elements).
- UML: TIP: prefix analysis Classes with an indicator such as an asterix (*Thing) to distinguish them from reverse/forward engineered design classes (Thing) !
- UML: TIP: use a Package for design(ed) elements (only)
- UML: TIPS: Class diagrams
- UML: TIP: hyperlink each and every important Class to a dedicated "focus" class diagram.
- UML: TIP: avoid drawing handles from Comments or notes to operations/attributes of a Class except in a dedicated "focus" Class diagram.
- UML: TIP: avoid revealing operations and attributes of Classes (and Interfaces, if possible) in more than one diagram (UNLESS you do so to illustrate an explicit collaboration with another Class with revealed Features) !
- UML: TIP: avoid revealing operations and attributes of Classes or Interfaces in Package overview diagrams.
- UML: TIP: DO NOT overuse the display of selected attributes or operations in their containers, as the approach is fragile against the addition of new attributes and operations.
- UML: TIP: make your architectural Class Diagrams look like "Class Collaborations" that correspond to related communication diagrams.
- UML: FAQ: May one draw an Association between Interfaces ?
- UML: TIP: Structure Compartment used to explore relationships between Properties
- UML: TIP: use naming convention Thing/Thing_ for Interface and default implementor Class pair
- UML: Tips for Composite Structure Diagrams
- UML reverse-engineering: code with the UML and your underlying model in mind
- UML: TIP: Java: use private fields/attributes rather than "hidden" anonymous features and local variables in method implementations to reveal usages as Properties.
- UML: TIP: consider how your code relates to finite state machine transitions.
- UML: TIP: consider how your implementation methods relate to collaborations, communications, and sequences.
- UML: TIP: code as though it were actually forward engineered from an advanced executable UML tool !
- The MetaTip: cognitive science, philosophy, and the UML are inseparable
- Tips for all UML diagram types
- Tutorial: the UML2 Component as a logical and graphical «wrapper» (MagicDraw-centric)
- UML: TIP: MagicDraw UML: unlike Package and Model, a Component does not always "steal ownership" of graphically contained elements.
- UML: TIP: MagicDraw UML: wrap every major Class in a logical «wrapper» Component of the same name.
- UML: TIP: MagicDraw UML: use the «wrapper» Component of a Class to wrap its related and associated nearest neighbour Classes and Interfaces
- UML: TIP: MagicDraw UML: avoid plain old Class Diagrams without graphically containing Classes within «wrapper» Components - except for the very simplest cases !
- UML: TIP: MagicDraw UML: DO NOT use reverse-engineered Components (like Class.java) as «wrapper» Components
- Diagramming with arbitrary logical «wrapper» Components
- UML: TIP: MagicDraw UML: you may use Components with lower case names to indicate arbitrary logical «wrapper» Components
- UML: TIP: MagicDraw UML: you may use custom Component stereotypes extending «wrapper» like «logical», «composition», and «inheritance» to indicate a wrapping context.
- UML: TIP: you may use long quoted parsed text snippets as the name of arbitrary logical «wrapper» Components.
- UML: TIP: do reverse-engineering on Class elements, do systems analysis with binding to the design" on a dedicated «wrapper» Component for that Class
- UML: MagicDraw UML: note use of logical and graphical grouping by «wrapper» Components.
- UML for Software Development
- Gallery: Tutorial: port-based software engineering with UML and Java
- View of a student as Interfaces representing viewpoints of different actors
- A PortlessHuman: poor mixed up Arthur
- Example: HiFi: port-based contract using an abstract "serviceProvider" Class
- Port-based engineering: don't leave home without it
- Port-based service orientation: Martha the SmarterHuman
- Pure Ports act on behalf of their parent
- Towards Executable UML
- Animated and simulated UML
- Gallery: Animated UML: mockup storyboard of a pretend Simpson's family interaction (from 2005)
- 0. Magicdraw UML content diagrams as executable UML2.0 animation sequencer
- 1. Homer is enjoying a beer watching tv peacefully in the lounge room
- 2. Bart rides skateboard over Homer, mocks him and laughs
- 3. Homer drinks beer in one shot and strangles Bart
- 4. Lisa laughs at both Homer and Bart then plays jazz on sax
- 5. Marge comes in to stop them making noise by waving a rolling pin
- Animated UML: The Simpsons: overview of Classes (with closed Interfaces)
- Animated UML: The Simpsons: overview of Classes (with open Interfaces)
- Simulating UML Activities and Statecharts (Finite State Machines)
- Gallery: Animated UML: mockup storyboard of a pretend Simpson's family interaction (from 2005)
- Java zone
- Java EE zone
- Gallery: UML Parsing Analysis demonstration: Your First Cup: An Introduction to the Java EE Platform
- 2. Understanding Java Platform, Enterprise Edition
- Overview of Enterprise Applications
- Tiered Applications
- In a multi-tiered application, the functionality of the application is separated into isolated functional areas, called tiers
- Typically, multi-tiered applications have a client tier, a middle tier, and a data tier (often called the enterprise information systems tier).
- The client tier consists of a client program that makes requests to the middle tier (nested Property version)
- The client tier consists of a client program that makes requests to the middle tier (associative version)
- The client tier consists of a client program that makes requests to the middle tier (composite version)
- The middle tier's business functions handle client requests and process application data, storing it in a permanent datastore in the data tier.
- The middle tier's business functions handle client requests and process application data, storing it in a permanent datastore in the data tier: NESTED PROPERTY FORM
- Java EE application development concentrates on the middle tier to make enterprise application management easier, more robust, and more secure.
- *Application_Tiered_typical
- The Client Tier
- The client tier consists of application clients that access a Java EE server and that are usually located on a different machine from the server.
- The clients make requests to the server
- The server processes the requests and returns a response back to the client.
- Many different types of applications can be Java EE clients, and they are not always, or even often Java applications.
- Clients can be a web browser, a standalone application, or other servers, and they run on a different machine from the Java EE server.
- The Web Tier
- The web tier consists of components that handle the interaction between clients and the business tier.
- Its primary tasks are the following:
- Dynamically generate content in various formats for the client
- Collect input from users of the client interface and return appropriate results from the components in the business tier.
- Collect input from users of the client interface and return appropriate results from the components in the business tier (as composite structure)
- Control the flow of screens or pages on the client.
- Maintain the state of data for a user's session
- Perform some basic logic and hold some data temporarily in JavaBeans components.
- Java EE Technologies Used in the Web Tier
- Java programming language classes that dynamically process requests and construct responses, usually for HTML pages
- Java programming language classes that dynamically process requests and construct responses, usually for HTML pages (port version)
- Java programming language classes that dynamically process requests and construct responses, usually for HTML pages (composite structure)
- Text-based documents that are compiled into servlets and define how dynamic content can be added to static pages, such as HTML pages.
- A tag library that encapsulates core functionality common to JSP pages
- Objects that act as temporary data stores for the pages of an application
- A user-interface component framework for web applications that allows you to include UI components (such as fields and buttons) on a page, convert and validate UI component data, save UI component data to server-side data stores, and maintain component st
- Facelets applications are a type of JavaServer Faces applications that use XHTML pages rather than JSP pages.
- A set of standard tags used in JSP and Facelets pages to refer to Java EE components
- The Business Tier
- The business tier consists of components that provide the business logic for an application
- Business logic is code that provides functionality to a particular business domain, like the financial industry, or an e-commerce site
- In a properly designed enterprise application, the core functionality exists in the business tier components.
- In a properly designed enterprise application, the core functionality exists in the business tier components (composite structure diagram)
- Java EE Technologies Used in the Business Tier
- The Enterprise Information Systems Tier
- The enterprise information systems (EIS) tier consists of database servers, enterprise resource planning systems, and other legacy data sources, like mainframes
- These resources typically are located on a separate machine than the Java EE server, and are accessed by components on the business tier
- Java EE Technologies Used in the EIS Tier.
- In a multi-tiered application, the functionality of the application is separated into isolated functional areas, called tiers
- Tiered Applications
- Java EE Servers
- A Java EE server is a server application that the implements the Java EE platform APIs and provides the standard Java EE services.
- Java EE servers are sometimes called application servers, because they allow you to serve application data to clients, much as how web servers serve web pages to web browsers.
- Java EE servers host several application component types that correspond to the tiers in a multi-tiered application
- The Java EE server provides services to these components in the form of a container
- Java EE Containers
- Java EE containers are the interface between the component and the lower-level functionality provided by the Java EE platform to support that component
- The Web Container
- The web container is the interface between web components and the web server.
- A web component can be a servlet, a JavaServer Faces Facelets page, or a JSP page.
- The container manages the component's lifecycle, dispatches requests to application components, and provides interfaces to context data, such as information about the current request.
- The Application Client Container
- The application client container is the interface between Java EE application clients, which are special Java SE applications that use Java EE server components, and the Java EE server.
- The application client container runs on the client machine, and is the gateway between the client application and the Java EE server components that the client uses.
- The application client container runs on the client machine, and is the gateway between the client application and the Java EE server components that the client uses (connected).
- The EJB Container
- The EJB container is the interface between enterprise beans, which provide the business logic in a Java EE application, and the Java EE server.
- The EJB container runs on the Java EE server and manages the execution of an application's enterprise beans.
- Overview of Enterprise Applications
- 3. Creating Your First Java EE Application
- Clone of This chapter gives an overview of the example application and step-by-step instructions on coding the example application.
- This chapter gives an overview of the example application and step-by-step instructions on coding the example application.
- Architecture of the Example Application
- The example application consists of three main components: DukesAgeResource, a JAX-RS RESTful web service; DukesBirthdayBean, an enterprise bean; and firstcup, a web application created with JavaServer Faces Facelets technology.
- DukesAgeResource is a JAX-RS resource that calculates the age of Duke, the Java mascot.
- Java EE 6 Tutorial: Types of Enterprise Beans
- DukesBirthdayBean is a stateless session bean that calculates the difference between the user's age and Duke's age.
- The firstcup web application is a JavaServer Faces Facelets application that accesses DukesAgeResource to display Duke's age, reads in a date provided by the user, accesses DukesBirthdayBean to calculate who is older, and then displays the difference ..
- The firstcup web application is a JavaServer Faces Facelets application that accesses DukesAgeResource to display Duke's age, reads in a date provided by the user, accesses DukesBirthdayBean to calculate who is older, and then displays the difference Act.
- The firstcup web application consists of the following:
- 2. Understanding Java Platform, Enterprise Edition
- Gallery: UML Parsing Analysis demonstration: Your First Cup: An Introduction to the Java EE Platform
- JSyn zone
- Gallery: UML reverse-engineering of JSyn classes (from 2005)
- JSyn: UML: overview
- JSyn: UML: com.softsynth.jsyn
- JSyn: UML: SynthCircuit
- JSyn: UML: SynthNote
- JSyn: UML: SynthSound with Ports
- JSyn: UML: SynthUnit: audio idioms
- JSyn: UML: SynthUnit: audio idioms
- JSyn: UML: SynthUnit: bus
- JSyn: UML: SynthUnit: filters
- JSyn: UML: SynthUnit: in out
- JSyn: UML: SynthUnit: maths
- JSyn: UML: SynthUnit: noise
- JSyn: UML: SynthUnit: oscillators
- JSyn: UML: SynthUnit: response
- JSyn: UML: envelopes
- JSyn: UML: misc
- JSyn: UML: samples
- Gallery: UML reverse-engineering of JSyn classes (from 2005)
- Java3D zone
- Gallery: UML Parsing Analysis models of the J3D tutorial
- 1.2.0. The Java 3D API.jpg
- 1.3.0. Building a Scene Graph
- 1.3.0.a. A Java 3D scene graphs is constructed of Node objects in parent-child relationships forming a tree structure.
- 1.3.0.b. Group vs. BranchGroup_ API notes
- 1.3.0.c. Each scene graph has a single VirtualUniverse.
- 1.3.0.d. Each scene graph path in a Java 3D scene graph completely specifies the state information of its leaf
- 1.3.0.e. Graphic representations of a scene graph can serve as design tool and_or documentation for Java 3D programs
- 1.3.1. High Level Java 3D API Class Hierarchy
- 1.4.0. Recipe for Writing Java 3D Programs
- 1.4.1. A Simple Recipe for Writing Java 3D Programs
- 1.5.0. Some Java 3D Terminology
- 1.6.0.a. Simple Recipe Example_ HelloJava3Da
- 1.6.0.b. Note there is no start the renderer step in either the basic or simple recipes
- 1.7.1 Combination of Transformations Example_ HelloJava3Db
- 1.9.0.a. Adding Animation Behavior In Java 3D
- 2.2.2 Node Components
- Gallery: UML Parsing Analysis models of the J3D tutorial
- Dynamic proxies in Java
- Galleries index: UML reverse-engineering of Java APIs
- JAFER toolkit for Z39.50
- JUNG zone
- JUNG example application: a semantic network with clustering
- Gallery: JUNG: UML Parsing Analysis of the documentation and reverse-engineered Java JUNG API (from 2003)
- JUNG: 0. introduction and overview
- JUNG: 3.user data: 1.class extension
- JUNG: 3.user data: 2.JUNG annotation
- JUNG: 3.user data: 3.Copying User Data
- JUNG: 3.user data: 4.Decorators, Indexers, and Labellers
- JUNG: 3.user data: 4.Decorators, Indexers, and Labellers
- JUNG: 5.algorithms: 0. Algorithms
- JUNG: 5.algorithms: 1. Graph Matrix Operations
- JUNG: 5.algorithms: 2. Clustering
- JUNG: 5.algorithms: 3. Topology, Paths, and Flows
- JUNG: 5.algorithms: 4. Importance
- JUNG: 5.algorithms: 6. Statistics
- JUNG: 6.filtering: 0. Filtering
- JUNG: 7.visualisation: 0. Visualization
- JUNG: 8.utilities: 0. Utilities
- Java and Aspect Oriented Programming (AOP)
- Java EE zone
- XML zone
- SysML zone
- C++ zone
- Eclipse zone
- Netbeans IDE zone
- Puredata synthesis zone
- Shibboleth zone
- Gallery: Shibboleth secure federated architecture in UML1.x
- Gallery: UML Parsing Analysis example: Shibboleth Specification_v1.0: in UML1.x (from 2004)
- 3.1 Players
- 3.1.a The following names are used in this document for the various functions
- 3.2.1 Basic SAML Domain Model: classes and subsystems
- 3.2.1 Basic SAML Domain Model: collaboration
- 3.2.2 Basic Shibboleth Domain Model
- 3.2.3 Other SAML-Shibboleth Differences
- 3.3.1 Origin
- 3.3.2 WAYF (Where Are You From)
- 3.3.3 Target
- 3.4 The Role of Sessions
- 3.5 Identifying the User
- 3.5.1 Collaboration: Identifying the User (via WAYF)
- 3.7 Glossary
- Snippet-driven engineering: a meta-process for documentation-driven software and systems engineering
- The title of a Snippet's focus web page is typically a sentence
- Every Parsing Snippet is a consumer of text for a source document known by URL, URI, ISBN, or by another unique source identifier.
- Every Snippet gets a dedicated analysis "focus" page in a CMS, and can appear as a "titled" link to its unique focus page
- A source document may be reconstructed (at least in part) as the union of all downstream Snippets that have it as source
- A Snippet may carry standardised editorial flags, error and warning flags, and ratings
- Each Snippet may be represented in a graphical language such as UML or SysML
- Where possible, the title of a Snippet should be digitally transferred from the source Document, not typed.
- Wherever and whenever possible, a Snippet should be bound to an executable or functioning expression of the represented text in the real-world
- Cascading Style Sheets (CSS) zone
- Tools and Tips
- JIRA zone
- Gallery: combining UML and SysML with JIRA issue tracking
- Abstraction of "resolvable" JIRA issue types as UML stereotypes
- Custom 'jRequirement' and 'feature' JIRA issue types represented as UML stereotypes combined with the SysML Requirement approach
- Custom 'recordable' JIRA issue types represented as UML stereotypes
- Overview of UML and SysML stereotypes for a feature-oriented development process for JIRA issues
- Representation of a feature-oriented software process as UML stereotypes corresponding to JIRA issue types
- UML State Machine Diagram analysis of a JIRA OmniTracker BUG issue workflow
- UML State Machine Diagram analysis of the workflow of a JIRA Feature issue type
- UML State Machine Diagram analysis of the workflow of a custom 'jRequirement' JIRA issue type
- UML State Machine Diagram analysis of the workflow of a custom 'recordable' JIRA issue type
- UML analysis models of the JIRA system, with custom issue types for feature-oriented software process
- Gallery: combining UML and SysML with JIRA issue tracking
- A review of Mac OS X timesheeting/tracking applications: Billings vs iBiz (and now Studiometry)
- Billings
- (Option to enforce) only one timer runs at a time.
- Access contributing items and their property sheets directly from reports
- Access stored timesheet data by SQL
- CPU usage efficiency
- Column-delimited data export (easily imported into spreadsheet applications)
- Convenient and quick editing of job event title and notes
- Customisable reports
- Default currency choice known to all newly created timers
- Documentation easily navigable
- Easily select all job events within a subset of projects
- Easily start/pause/restart timers (without completing/closing job event)
- Easy access to start/stop timestamped logging of job sub-events
- Editable log of start/stop of job sub-events
- Export reports (not invoices) as PDF
- Filtering and sorting of job events by date across projects and/or client
- Financial information cent-accurate
- Generate invoice/report for a given fine-grained period (hh:mm accurate)
- Hyperlink job event to external resource as URL
- Job event groups with weighted time and service rate averages of sub-events
- Newly created timer knows project/client through context or selection
- Option to show unbilled items in reports (and/or invoices)
- Pie-charts and percentages of time spent by project/client.
- Reliable export of start/finish job event data to iCal
- Tag completed job event by completion state: like PASSED, FAILED, etc.
- Studiometry
- Access stored timesheet data by SQL
- Associate project with local files
- Default currency choice known to all newly created timers
- Easily start/pause/restart timers (without completing/closing job event)
- Hyperlink job event to external resource as URL
- Newly created timer knows project/client through context or selection
- iBiz
- (Option to enforce) only one timer runs at a time.
- Access contributing items and their property sheets directly from reports
- Access stored timesheet data by SQL
- CPU usage efficiency
- Column-delimited data export (easily imported into spreadsheet applications)
- Convenient and quick editing of job event title and notes
- Customisable reports
- Documentation easily navigable
- Easily select all job events within a subset of projects
- Easily start/pause/restart timers (without completing/closing job event)
- Easy access to start/stop timestamped logging of job sub-events
- Editable log of start/stop of job sub-events
- Export reports (not invoices) as PDF
- Filtering and sorting of job events by date across projects and/or client
- Financial information cent-accurate
- Generate invoice/report for a given fine-grained period (hh:mm accurate)
- Hyperlink job event to external resource as URL
- Job event groups with weighted time and service rate averages of sub-events
- Newly created timer knows project/client through context or selection
- Option to show unbilled items in reports and/or invoices
- Pie-charts and percentages of time spent by project/client.
- Reliable export of start/finish job event data to iCal
- Tag completed job event by completion state: like PASSED, FAILED, etc.
- Billings
- Firebug
- Firefox
- Graphics tools zone
- MATLAB
- Mac OS X
- OPEN FEEDBACK: Expose Spaces: poor comparison with the KDE window manager and other windowing issues
- 1. It should be possible to allocate a specific _window_ from an application to a given space, not the entire application's window set at once !
- In KDE it is much easier: one can easily assign (by selecting a _named_ space from a button on the window bar) a given window to any space ..
- If this is possible in Spaces please forgive my critique and let me know how.
- 2. In KDE when one pulls up the window list one gets a nice VERTICAL 2-level tree with the 1st level a selectable Space _name_, and the 2nd level it the specific window selection list ..
- 3. In KDE one can name each space, typically by project, as shown
- 4. The horizontal icon-based AppleKey+Tab equivalent is also better in KDE, because it only lists those window within a given space (and those that are sticky), so you stay within the zone.
- in KDE, it gives a selectable list of all windows in that space, with an indicator of whether it is open or not
- a little bit more R&D first might have helped
- I would like to say that Spaces is better than nothing, but in fact it is more annoying than just plowing through the full window list in most cases for my work,
- 1. WISH: ERROR: Ability to allocate a Window (not a whole Application) to a Space (or better instructions on how to if already present)
- 2. WISH: A vertical Window list with some sub-structure by (named) Space.
- 3. WISH: Named Spaces, at least as an option or on hover over a Space icon.
- 4. WISH: Horizontal icon view of Windows (optionally) only shows those Windows (with Application indicator) from the current Space, rather than the open Applications
- 5. WISH: Nested selectable list of Windows (with Application indicator icon) currently allocated to a given space when clicking on the Spaces toolbar icon.
- ISSUE: COMMAND+TAB between Windows in different Spaces of different Applications (when many Windows open) does not toggle properly, it moves to another window in the 2nd Space
- ISSUE: after F8 to Spaces view it is hard to see the title of the reduced-size Windows, because there is no title no hover !
- ISSUE: have to leave the main Desktop view to see what the Spaces are
- ISSUE: can't access Spaces view from the Spaces icon button in the main menu bar
- Gallery: snapshots of aspects of KDE3.5 window manager widgets
- KDE 3.5: mini pager in KPanel, with (optionally) named desktops
- KDE3.5: window list with multiple desktop structure
- KDE3.5: easy to move a window from one desktop to another using top-left corner window menu
- KDE3.5: Desktop Pager: floating widget with overview of desktops and window positions
- KDE3.5: moving window from one desktop to another using KPager mini-app view
- KDE3.5: ALT TAB gives nice vertical list with rows indicating the application by icon and the window title as text
- KDE3.5: active Application (taskbar) icon+title buttons with window stacks in KPanel
- PS: Can somebody please tell me how to really maximise (not just enlarge) a window to fit the entire screen in one click on any window ?
- OPEN FEEDBACK: Expose Spaces: poor comparison with the KDE window manager and other windowing issues
- JIRA zone
- UML2.3 metaclasses and metamodel overview using hyperlinked UML Parsing Analysis [ARCHIVAL]
- Source: UML2.3 superstructure: formal/2010-05-05 (as PDF)
- Notes about this (partial) UML Parsing Analysis of the UML superstructure specification
- Copyright in all text quoted from the UML specifications and repeated here for educational purposes as hyperlinked text "snippets", and in all images repeated from the UML specifications, remains with the Object Management Group (OMG)
- It is not (currently) the intention of this UML Parsing Analysis demonstration based on the UML superstructure specification to reproduce the entire UML specification online; the emphasis is on only those aspects of UML that support SysML.
- 11.3.10 CallOperationAction (from BasicActions)
- 11.3.19 InputPin (from BasicActions)
- 11.3.20 InvocationAction (from BasicActions)
- 11.3.27 OutputPin (from BasicActions)
- Description
- Notation
- Semantics
- For each execution, an action cannot terminate itself unless it can put at least as many values on its output pins as required by the lower multiplicity on those pins.
- The values are actually put in the pins once the action completes.
- Values that may remain on the output pins from previous executions are not included in meeting this minimum multiplicity requirement.
- An action may not put more values in an output pin in a single execution than the upper multiplicity of the pin.
- 11.3.28 Pin (from BasicActions)
- 11.3.3 Action (from BasicActions)
- Associations
- Description
- Notation
- Semantics
- An action execution represents the run-time behavior of executing an action within a specific behavior execution.
- As Action is an abstract class, all action executions will be executions of specific kinds of actions.
- When the action executes, and what its actual inputs are, is determined by the concrete action and the behaviors in which it is used.
- 11.3.51 ValuePin (from BasicActions)
- 11.3.8 CallAction (from BasicActions)
- Associations
- Attributes
- Constraints
- Only synchronous call actions can have result pins.
- The number and order of argument pins must be the same as the number and order of parameters of the invoked behavior or behavioral feature. Pins are matched to parameters by order.
- The type, ordering, and multiplicity of an argument pin must be the same as the corresponding parameter of the behavior or behavioral feature.
- Description
- Semantics
- Parameters on behaviors and operations are totally ordered lists. [..]
- To match parameters to pins on call actions, select the sublist of that list that corresponds to in and inout owned parameters (i.e., Behavior.ownedParameter).
- The input pins on Action::input are matched in order against these parameters in the sublist order.
- Then take the sublist of the parameter list that corresponds to out, inout, and return parameters.
- The output pins on Action::output are matched in order against these parameters in sublist order.
- If the behavior invoked by a call action is not reentrant, then no more than one execution of it will exist at any given time.
- An invocation of a non-reentrant behavior does not start the behavior when the behavior is already executing.
- An invocation of a reentrant behavior may start a new execution of the behavior when offered the required tokens, even if the behavior is already executing. [..]
- See children of CallAction.
- Parameters on behaviors and operations are totally ordered lists. [..]
- 11.3.9 CallBehaviorAction (from BasicActions)
- Associations
- Constraints
- The number of argument pins and the number of parameters of the behavior of type in and in-out must be equal.
- The number of result pins and the number of parameters of the behavior of type return, out, and in-out must be equal.
- The type, ordering, and multiplicity of an argument or result pin is derived from the corresponding parameter of the behavior.
- Description
- CallBehaviorAction is a call action that invokes a behavior directly rather than invoking a behavioral feature that, in turn, results in the invocation of that behavior.
- The argument values of the action are available to the execution of the invoked behavior.
- For synchronous calls the execution of the call behavior action waits until the execution of the invoked behavior completes and a result is returned on its output pin.
- The action completes immediately without a result, if the call is asynchronous.
- Notation
- Presentation Options
- Semantics
- 12.3.10 ActivityPartition (from IntermediateActivities)
- 12.3.19 ControlFlow (from BasicActivities)
- 12.3.37 ObjectFlow (from BasicActivities, CompleteActivities)
- An object flow is an activity edge that can have objects or data passing along it
- Notation
- An object flow is notated by an arrowed line.
- In Figure 12.107, upper right, the two object flow arrows denote a single object flow edge between two pins in the underlying model, as shown in the lower middle of the figure.
- See also the discussion on Figure 12.120 on page 415.
- Figure 12.107 - Object flow notations
- 12.3.38 ObjectNode (from BasicActivities, CompleteActivities)
- 12.3.39 ObjectNodeOrderingKind (from CompleteActivities)
- 12.3.4 Activity (from BasicActivities, CompleteActivities, FundamentalActivities, StructuredActivities)
- An activity is the specification of parameterized behavior as the coordinated sequencing of subordinate units whose individual elements are actions.
- Associations
- Attributes
- Constraints
- Description
- An activity specifies the coordination of executions of subordinate behaviors, using a control and data flow model. [..]
- The subordinate behaviors coordinated by these models may be initiated because other behaviors in the model finish executing, because objects and data become available, or because events occur external to the flow.
- The flow of execution is modeled as activity nodes connected by activity edges.
- A node can be the execution of a subordinate behavior, such as an arithmetic computation, a call to an operation, or manipulation of object contents.
- Activity nodes also include flow-of control constructs, such as synchronization, decision, and concurrency control.
- Activities may form invocation hierarchies invoking other activities, ultimately resolving to individual actions.
- In an object-oriented model, activities are usually invoked indirectly as methods bound to operations that are directly invoked.
- Activities may describe procedural computation. [..]
- Activities may be applied to organizational modeling for business process engineering and workflow. [..]
- Activities can also be used for information system modeling to specify system level processes.
- Activities may contain actions of various kinds: [..]
- Actions have no further decomposition in the activity containing them. [..]
- Most of the constructs in the Activity clause deal with various mechanisms for sequencing the flow of control and data among the actions: [..]
- Object flows for sequencing data produced by one node that is used by other nodes.
- Control flows for sequencing the execution of nodes.
- Control nodes to structure control and object flow. [..]
- Activity generalization to replace nodes and edges.
- Object nodes to represent objects and data as they flow in and out of invoked behaviors, or to represent collections of tokens waiting to move downstream.
- Composite nodes to represent structured flow-of-control constructs, such as loops and conditionals.
- Partitions to organize lower-level activities according to various criteria, such as the real-world organization responsible for their performance.
- Interruptible regions and exceptions to represent deviations from the normal, mainline flow of control.
- An activity specifies the coordination of executions of subordinate behaviors, using a control and data flow model. [..]
- Examples
- Notation
- Presentation Options
- Semantic Variation Points
- Semantics
- There are actions that invoke activities (directly by “CallBehaviorAction (from BasicActions)” on page 250 or indirectly as methods by “CallOperationAction (from BasicActions)” on page 252).
- 12.3.43 ParameterSet (from CompleteActivities)
- 12.3.5 ActivityEdge (from BasicActivities, CompleteActivities, CompleteStructuredActivities, IntermediateActivities)
- 12.3.7 ActivityGroup (from BasicActivities, FundamentalActivities)
- 12.3.8 ActivityNode (from BasicActivities, CompleteActivities, FundamentalActivities, IntermediateActivities, CompleteStructuredActivities)
- 13.3.2 Behavior (from BasicBehaviors)
- Associations
- Attributes
- Constraints
- The parameters of the behavior must match the parameters of the implemented behavioral feature.
- The implemented behavioral feature must be a feature (possibly inherited) of the context classifier of the behavior.
- If the implemented behavioral feature has been redefined in the ancestors of the owner of the behavior, then the behavior must realize the latest redefining behavioral feature
- There may be at most one behavior for a given pairing of classifier (as owner of the behavior) and behavioral feature (as specification of the behavior).
- Description
- Behavior is a specification of how its context classifier changes state over time.
- This specification may be either a definition of possible behavior execution or emergent behavior, or a selective illustration of an interesting subset of possible executions.
- The latter form is typically used for capturing examples, such as a trace of a particular execution.
- A classifier behavior is always a definition of behavior and not an illustration.
- It describes the sequence of state changes an instance of a classifier may undergo in the course of its lifetime.
- Its precise semantics depends on the kind of classifier.
- When a behavior is associated as the method of a behavioral feature, it defines the implementation of that feature (i.e., the computation that generates the effects of the behavioral feature).
- For example, the classifier behavior of a collaboration represents emergent behavior of all the parts, whereas the classifier behavior of a class is just the behavior of instances of the class separated from the behaviors of any of its parts.
- Semantic Variation Points
- The means by which requests are transported to their target depend on the type of requesting action, the target, the properties of the communication medium, and numerous other factors
- In some cases, this is instantaneous and completely reliable while in others it may involve transmission delays of variable duration, loss of requests, reordering, or duplication (see also the discussion on page 439).
- How the parameters of behavioral features or a behavior match the parameters of a behavioral feature is a semantic variation point (see BehavioralFeature on page 449).
- Semantics
- The detailed semantics of behavior is determined by its subtypes.
- The features of the context classifier and elements that are visible to the context classifier are also visible to the behavior, provided that is allowed by the visibility rules.
- When a behavior is invoked, its attributes and parameters (if any) are created and appropriately initialized.
- Upon invocation, the arguments of the original invocation action are made available to the new behavior execution corresponding to its parameters with direction ‘in’ and ‘inout,’ if any.
- When a behavior completes its execution, a value or set of values is returned corresponding to each parameter with direction ‘out,’ ‘inout,’ or ‘return,’ if any.
- If such a parameter has a default value associated and the behavior does not explicitly generate a value for this parameter, the default value describes the value that will be returned corresponding to this parameter.
- If the invocation was synchronous, any return values from the behavior execution are returned to the original caller, which is unblocked and allowed to continue execution.
- The behavior executes within its context object, independently of and concurrently with any existing behavior executions.
- The object that is the context of the behavior manages the input pool holding the event occurrences to which a behavior may respond (see 13.3.4, “BehavioredClassifier (from BasicBehaviors, Communications),” on page 450).
- As an object may have a number of behaviors associated, all these behaviors may access the same input pool.
- The object ensures that each event occurrence on the input pool is consumed by only one behavior.
- When a behavior is instantiated as an object, it is its own context.
- 13.3.4 BehavioredClassifier (from BasicBehaviors, Communications)
- 15.3.11 State (from BehaviorStateMachines, ProtocolStateMachines)
- 15.3.12 StateMachine (from BehaviorStateMachines)
- 15.3.14 Transition (from BehaviorStateMachines)
- 15.3.16 Vertex (from BehaviorStateMachines)
- 16.3.1 Actor (from UseCases)
- An actor specifies a role played by a user or any other system that interacts with the subject.
- (The term “role” is used informally here and does not necessarily imply the technical definition of that term found elsewhere in this specification.)
- Constraints
- Description
- An Actor models a type of role played by an entity that interacts with the subject (e.g., by exchanging signals and data), ..
- .. but which is external to the subject (i.e., in the sense that an instance of an actor is not a part of the instance of its corresponding subject).
- Actors may represent roles played by human users, external hardware, or other subjects.
- Note that an actor does not necessarily represent a specific physical entity but merely a particular facet (i.e., “role”) of some entity that is relevant to the specification of its associated use cases.
- Since an actor is external to the subject, it is typically defined in the same classifier or package that incorporates the subject classifier.
- Thus, a single physical instance may play the role of several different actors and, conversely, a given actor may be played by multiple different instances.
- Notation
- Presentation Options
- Semantics
- Actors model entities external to the subject.
- For example, a computer user may activate a given software application multiple times concurrently or at different points in time.
- When an external entity interacts with the subject, it plays the role of a specific actor.
- When an actor has an association to a use case with a multiplicity that is greater than one at the use case end, it means that a given actor can be involved in multiple use cases of that type.
- The specific nature of this multiple involvement depends on the case on hand and is not defined in this specification.
- Thus, an actor may initiate multiple use cases in parallel (concurrently) or they may be mutually exclusive in time.
- Style Guidelines
- 16.3.6 UseCase (from UseCases)
- 17.3.1 Model (from Models)
- A model captures a view of a physical system.
- It is an abstraction of the physical system, with a certain purpose.
- This purpose determines what is to be included in the model and what is irrelevant.
- Thus the model completely describes those aspects of the physical system that are relevant to the purpose of the model, at the appropriate level of detail.
- Attributes
- Description
- A Model may also contain a set of elements that represents the environment of the system, typically Actors, together with their interrelationships, such as Associations and Dependencies.
- The Model construct is defined as a Package.
- It contains a (hierarchical) set of elements that together describe the physical system being modeled.
- 7.3.1 Abstraction (from Dependencies)
- 7.3.10 Constraint (from Kernel)
- A constraint is a condition or restriction expressed in natural language text or in a machine readable language for the purpose of declaring some of the semantics of an element.
- Associations
- Constraints
- Description
- Constraint contains a ValueSpecification that specifies additional semantics for one or more elements.
- Certain kinds of constraints (such as an association “xor” constraint) are predefined in UML, others may be user-defined.
- A user-defined Constraint is described using a specified language, whose syntax and interpretation is a tool responsibility.
- One predefined language for writing constraints is OCL.
- In some situations, a programming language such as Java may be appropriate for expressing a constraint.
- In other situations natural language may be used.
- Constraint is a condition (a Boolean expression) that restricts the extension of the associated element beyond what is imposed by the other language constructs applied to that element.
- Constraint contains an optional name, although they are commonly unnamed.
- Examples
- Notation
- Presentation Options
- Semantics
- 7.3.11 DataType (from Kernel)
- Associations
- Description
- A data type is a type whose instances are identified only by their value.
- A DataType may contain attributes to support the modeling of structured data types.
- A typical use of data types would be to represent programming language primitive types or CORBA basic types.
- For example, integer and string types are often treated as data types.
- Examples
- Notation
- Semantic Variation Points
- Semantics
- A data type is a special kind of classifier, similar to a class.
- It differs from a class in that instances of a data type are identified only by their value.
- All copies of an instance of a data type and any instances of that data type with the same value are considered to be equal instances.
- If a data type has attributes, then instances of that data type will contain attribute values matching the attributes.
- Instances of a data type that have attributes (i.e., is a structured data type) are considered to be equal if the structure is the same and the values of the corresponding attributes are equal.
- 7.3.12 Dependency (from Dependencies)
- Associations
- Description
- A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation.
- This means that the complete semantics of the depending elements is either semantically or structurally dependent on the definition of the supplier element(s).
- Examples
- Notation
- A dependency is shown as a dashed arrow between two model elements.
- The model element at the tail of the arrow (the client) depends on the model element at the arrowhead (the supplier).
- The arrow may be labeled with an optional stereotype and an optional name.
- It is possible to have a set of elements for the client or supplier.
- In this case, one or more arrows with their tails on the clients are connected to the tails of one or more arrows with their heads on the suppliers.
- A small dot can be placed on the junction if desired.
- A note on the dependency should be attached at the junction point.
- Figure 7.37 - Notation for a dependency between two elements
- Semantics
- A dependency signifies a supplier/client relationship between model elements where the modification of the supplier may impact the client model elements.
- A dependency implies the semantics of the client is not complete without the supplier.
- The presence of dependency relationships in a model does not have any runtime semantics implications, it is all given in terms of the model-elements that participate in the relationship, not in terms of their instances.
- 7.3.13 DirectedRelationship (from Kernel)
- 7.3.14 Element (from Kernel)
- 7.3.15 ElementImport (from Kernel)
- 7.3.18 Expression (from Kernel)
- 7.3.19 Feature (from Kernel)
- A feature declares a behavioral or structural characteristic of instances of classifiers.
- Associations
- Attributes
- Changes from previous UML
- Description
- Notation
- Presentation Options
- Semantic Variation Points
- With regard to static features, two alternative semantics are recognized.
- A static feature may have different values for different featuring classifiers, or the same value for all featuring classifiers.
- In accord with this semantic variation point, inheritance of values for static features is permitted but not required by UML2.
- Such inheritance is encouraged when modeling systems will be coded in languages, such as C++, Java, and C#, which stipulate inheritance of values for static features.
- Semantics
- A feature represents some characteristic for its featuring classifiers; this characteristic may be of the classifier’s instances considered individually (not static), or of the classifier itself (static).
- A Feature can be a feature of multiple classifiers.
- The same feature cannot be static in one context but not another.
- 7.3.2 AggregationKind (from Kernel)
- 7.3.20 Generalization (from Kernel, PowerTypes)
- A generalization is a taxonomic relationship between a more general classifier and a more specific classifier.
- Each instance of the specific classifier is also an indirect instance of the general classifier.
- Thus, the specific classifier inherits the features of the more general classifier.
- Associations
- Attributes
- Constraints
- Description
- Examples
- Notation
- A Generalization is shown as a line with a hollow triangle as an arrowhead between the symbols representing the involved classifiers.
- The arrowhead points to the symbol representing the general classifier.
- See the example sub clause below.
- This notation is referred to as the “separate target style.”
- Presentation Options
- Semantics
- Where a generalization relates a specific classifier to a general classifier, each instance of the specific classifier is also an instance of the general classifier.
- Therefore, features specified for instances of the general classifier are implicitly specified for instances of the specific classifier.
- Any constraint applying to instances of the general classifier also applies to instances of the specific classifier.
- 7.3.21 GeneralizationSet (from PowerTypes)
- 7.3.22 InstanceSpecification (from Kernel)
- An instance specification is a model element that represents an instance in a modeled system.
- Associations
- classifier : Classifier [0..*]
- slot : Slot [*]
- A slot giving the value or values of a structural feature of the instance.
- An instance specification can have one slot per structural feature of its classifiers, including inherited features.
- It is not necessary to model a slot for each structural feature, in which case the instance specification is a partial description
- Subsets Element::ownedElement
- specification : ValueSpecification [0..1]
- Description
- Notation
- An instance specification is depicted using the same notation as its classifier, but in place of the classifier name appears an underlined concatenation of the instance name (if any), a colon (‘:’) and the classifier name or names.
- The convention for showing multiple classifiers is to separate their names by commas.
- Names are optional for UML classifiers and instance specifications.
- The absence of a name in a diagram may reflect its absence in the underlying model.
- The standard notation for an anonymous instance specification of an unnamed classifier is an underlined colon (‘:’).
- If an instance specification has a value specification as its specification, the value specification is shown either after an equal sign (“=”) following the name, or without an equal sign below the name.
- If the instance specification is shown using an enclosing shape (such as a rectangle) that contains the name, the value specification is shown within the enclosing shape.
- Figure 7.52 - Specification of an instance of String
- Slots are shown using similar notation to that of the corresponding structural features.
- Where a feature would be shown textually in a compartment, a slot for that feature can be shown textually as a feature name followed by an equal sign (‘=’) and a value specification.
- Other properties of the feature, such as its type, can optionally be shown.
- Figure 7.53 - Slots with values
- An instance specification whose classifier is an association represents a link and is shown using the same notation as for an association, but the solid path or paths connect instance specifications rather than classifiers.
- End names can adorn the ends.
- It is not necessary to show an underlined name where it is clear from its connection to instance specifications that it represents a link and not an association.
- Navigation arrows can be shown, but if shown, they must agree with the navigation of the association ends.
- Figure 7.54 - Instance specifications representing two objects connected by a link
- Presentation Options
- A slot value for an attribute can be shown using a notation similar to that for a link.
- A solid path runs from the owning instance specification to the target instance specification representing the slot value, and the name of the attribute adorns the target end of the path.
- Navigability, if shown, must be only in the direction of the target.
- 7.3.23 InstanceValue (from Kernel)
- 7.3.24 Interface (from Interfaces)
- Associations
- Description
- An interface is a kind of classifier that represents a declaration of a set of coherent public features and obligations
- An interface specifies a contract; any instance of a classifier that realizes the interface must fulfill that contract.
- The obligations that may be associated with an interface are in the form of various kinds of constraints (such as pre- and postconditions) or protocol specifications, which may impose ordering restrictions on interactions through the interface.
- Since interfaces are declarations, they are not instantiable.
- Instead, an interface specification is implemented by an instance of an instantiable classifier, which means that the instantiable classifier presents a public facade that conforms to the interface specification.
- Note that a given classifier may implement more than one interface and that an interface may be implemented by a number of different classifiers (see “InterfaceRealization (from Interfaces)” on page 91).
- 7.3.25 InterfaceRealization (from Interfaces)
- 7.3.3 Association (from Kernel)
- An association describes a set of tuples whose values refer to typed instances.
- Associations
- Attributes
- Description
- An association specifies a semantic relationship that can occur between typed instances.
- It has at least two ends represented by properties, each of which is connected to the type of the end.
- More than one end of the association may have the same type.
- An end property of an association that is owned by an end class or that is a navigable owned end of the association indicates that the association is navigable from the opposite ends; otherwise, the association is not navigable from the opposite ends.
- An instance of an association is called a link.[ ]
- A link is a tuple with one value for each end of the association, where each value is an instance of the type of the end.
- 7.3.32 MultiplicityElement (from Kernel)
- A multiplicity is a definition of an inclusive interval of non-negative integers beginning with a lower bound and ending with a (possibly infinite) upper bound.
- Additional Operations
- Associations
- Attributes
- Constraints
- Description
- Examples
- Notation
- Presentation Options
- Semantics
- A multiplicity element embeds this information to specify the allowable cardinalities for an instantiation of this element.
- 7.3.33 NamedElement (from Kernel, Dependencies)
- A named element represents elements that may have a name.
- The name is used for identification of the named element within the namespace in which it is defined.
- A named element also has a qualified name that allows it to be unambiguously identified within a hierarchy of nested namespaces.
- NamedElement is an abstract metaclass.
- Associations
- Attributes
- Semantics
- The name attribute is used for identification of the named element within namespaces where its name is accessible.
- Note that the attribute has a multiplicity of [0..1] that provides for the possibility of the absence of a name (which is different from the empty name).
- The visibility attribute provides the means to constrain the usage of a named element, either in namespaces or in access to the element.
- It is intended for use in conjunction with import, generalization, and access mechanisms.
- 7.3.34 Namespace (from Kernel)
- 7.3.36 Operation (from Kernel, Interfaces)
- 7.3.37 Package (from Kernel)
- 7.3.38 PackageableElement (from Kernel)
- 7.3.39 PackageImport (from Kernel)
- 7.3.4 AssociationClass (from AssociationClasses)
- A model element that has both association and class properties.
- An AssociationClass can be seen as an association that also has class properties, or as a class that also has association properties.
- It not only connects a set of classifiers but also defines a set of features that belong to the relationship itself and not to any of the classifiers.
- 7.3.41 Parameter (from Kernel)
- 7.3.42 ParameterDirectionKind (from Kernel)
- 7.3.44 Property (from Kernel, AssociationClasses, Interfaces)
- Associations
- association: Association [0..1]
- owningAssociation: Association [0..1]
- datatype : DataType [0..1]
- defaultValue: ValueSpecification [0..1]
- redefinedProperty : Property [*]
- subsettedProperty : Property [*]
- / opposite : Property [0..1]
- class : Class [0..1]
- associationEnd : Property [0..1]
- qualifier : Property [*]
- interface: Interface [0..1]
- Attributes
- Constraints
- If this property is owned by a class associated with a binary association, and the other end of the association is also owned by a class, then opposite gives the other end.
- A multiplicity on an aggregate end of a composite aggregation must not have an upper bound greater than 1.
- Subsetting may only occur when the context of the subsetting property conforms to the context of the subsetted property.
- A redefined property must be inherited from a more general classifier containing the redefining property.
- A subsetting property may strengthen the type of the subsetted property, and its upper bound may be less.
- Only a navigable property can be marked as readOnly.
- A derived union is derived.
- A derived union is read only.
- The value of isComposite is true only if aggregation is composite.
- A Property cannot be subset by a Property with the same name
- Description
- Semantics
- Associations
- 7.3.45 Realization (from Dependencies)
- 7.3.46 RedefinableElement (from Kernel)
- A redefinable element is an element that, when defined in the context of a classifier, can be redefined more specifically or differently in the context of another classifier that specializes (directly or indirectly) the context classifier.
- Associations
- Attributes
- isLeaf: Boolean
- Indicates whether it is possible to further redefine a RedefinableElement.
- If the value is true, then it is not possible to further redefine the RedefinableElement.
- Note that this property is preserved through package merge operations; that is, the capability to redefine a RedefinableElement (i.e., isLeaf=false) must be preserved in the resulting RedefinableElement of a package merge operation ..
- Default value is false
- isLeaf: Boolean
- Semantics
- 7.3.47 Relationship (from Kernel)
- 7.3.48 Slot (from Kernel)
- 7.3.49 StructuralFeature (from Kernel)
- 7.3.5 BehavioralFeature (from Kernel)
- 7.3.50 Substitution (from Dependencies)
- Associations
- Description
- A substitution is a relationship between two classifiers which signifies that the substitutingClassifier complies with the contract specified by the contract classifier.
- This implies that instances of the substitutingClassifier are runtime substitutable where instances of the contract classifier are expected.
- Examples
- Notation
- Semantics
- The substitution relationship denotes runtime substitutability that is not based on specialization.
- Substitution, unlike specialization, does not imply inheritance of structure, but only compliance of publicly available contracts.
- A substitution like relationship is instrumental to specify runtime substitutability for domains that do not support specialization such as certain component technologies.
- It requires that (1) interfaces implemented by the contract classifier are also implemented by the substituting classifier, or else the substituting classifier implements a more specialized interface type.
- And, (2) the any port owned by the contract classifier has a matching port (see ports) owned by the substituting classifier.
- 7.3.51 Type (from Kernel)
- 7.3.52 TypedElement (from Kernel)
- 7.3.54 ValueSpecification (from Kernel)
- 7.3.55 VisibilityKind (from Kernel)
- 7.3.6 BehavioredClassifier (from Interfaces)
- 7.3.7 Class (from Kernel)
- A class describes a set of objects that share the same specifications of features, constraints, and semantics.
- Additional Operations
- Associations
- Attributes
- Description
- Examples
- Notation
- Presentation Options
- Semantics
- The purpose of a class is to specify a classification of objects and to specify the features that characterize the structure and behavior of those objects.
- Objects of a class must contain values for each attribute that is a member of that class, in accordance with the characteristics of the attribute, for example its type and multiplicity.
- When an object is instantiated in a class, for every attribute of the class that has a specified default, if an initial value of the attribute is not specified explicitly for the instantiation, then the default value specification is evaluated to set ..
- Operations of a class can be invoked on an object, given a particular set of substitutions for the parameters of the operation.
- An operation invocation may cause changes to the values of the attributes of that object
- It may also return a value as a result, where a result type for the operation has been defined.
- Operation invocations may also cause changes in value to the attributes of other objects that can be navigated to, directly or indirectly, from the object on which the operation is invoked, to its output parameters, to objects navigable from its ..
- Operation invocations may also cause the creation and deletion of objects.
- A class cannot access private features of another class, or protected features on another class that is not its supertype.
- When creating and deleting associations, at least one end must allow access to the class.
- 7.3.8 Classifier (from Kernel, Dependencies, PowerTypes)
- A classifier is a classification of instances, it describes a set of instances that have features in common.
- Associations
- Attributes
- Constraints
- Description
- A classifier is a namespace whose members can include features.
- A classifier is a type and can own generalizations, thereby making it possible to define generalization relationships to other classifiers.
- Classifier is an abstract metaclass.
- A classifier can specify a generalization hierarchy by referencing its general classifiers.
- A classifier is a redefinable element, meaning that it is possible to redefine nested classifiers.
- Notation
- Presentation Options
- Semantic Variation Points
- Semantics
- Style Guidelines
- 7.3.9 Comment (from Kernel)
- 9.3.11 Port (from Ports)
- 9.3.12 Property (from InternalStructures)
- 9.3.13 StructuredClassifier (from InternalStructures)
- Associations
- Constraints
- Description
- Semantics
- The multiplicities on the structural features and connector ends indicate the number of instances (objects and links) that may be created within an instance of the containing classifier, ..
- .. either when the instance of the containing classifier is created, or in the case of links, when an object is added as the value of a role, or at a later time.
- 9.3.2 Classifier (from InternalStructures, Collaborations)
- 9.3.3 Collaboration (from Collaborations)
- A collaboration describes a structure of collaborating elements (roles), each performing a specialized function, which collectively accomplish some desired functionality.
- Its primary purpose is to explain how a system works and, therefore, it typically only incorporates those aspects of reality that are deemed relevant to the explanation.
- Thus, details, such as the identity or precise class of the actual participating instances are suppressed.
- 9.3.5 ConnectableElement (from InternalStructures)
- 9.3.6 Connector (from InternalStructures)
- 9.3.7 ConnectorEnd (from InternalStructures, Ports)
- Associations
- Constraints
- If a connector end is attached to a port of the containing classifier, partWithPort will be empty.
- If a connector end references a partWithPort, then the role must be a port that is defined by the type of the partWithPort.
- The property held in self.partWithPort must not be a Port.
- The multiplicity of the connector end may not be more general than the multiplicity of the association typing the owning connector.
- Description
- 9.3.8 EncapsulatedClassifier (from Ports)
- Annex C: Standard Stereotypes (normative)
- «trace»
- Description
- Specifies a trace relationship between model elements or sets of model elements that represent the same concept in different models.
- Traces are mainly used for tracking requirements and changes across models.
- Since model changes can occur in both directions, the directionality of the dependency can often be ignored.
- The mapping specifies the relationship between the two, but it is rarely computable and is usually informal.
- Description
- «trace»
- Sponsors are sought for the online UML and SysML specification Parsing Analysis projects
- Metaclasses: dynamic query view
- Packages
- AssociationClasses
- BasicActions
- BasicActivities
- BasicBehaviors
- BehaviorStateMachines
- Collaborations
- Communications
- CompleteActivities
- CompleteStructuredActivities
- Dependencies
- FundamentalActivities
- Interfaces
- IntermediateActivities
- InternalStructures
- Kernel
- Models
- Nodes
- Ports
- PowerTypes
- PrimitiveTypes
- ProtocolStateMachines
- StructuredActivities
- UseCases
- Properties (of Metaclass attributes and associations): dynamic query view
- SysML1.2 specification overview using hyperlinked SysML Parsing Analysis [ARCHIVAL]
- SysML1.2 Specification (with changebars) [as PDF]: formal/2010-06-02
- Part II - Structural Constructs
- 7 Model Elements
- 8 Blocks
- 8.3.1 Diagram Extensions
- 8.3.1.1 Block Definition Diagram
- Block and ValueType Definitions
- Default «block» stereotype on unlabeled box
- Labeled compartments
- Constraints compartment
- Namespace compartment
- Structure compartment
- Default multiplicities
- SysML defines defaults for multiplicities on the ends of specific types of associations.
- A part or shared association has a default multiplicity of [0..1] on the black or white diamond end.
- A unidirectional association has a default multiplicity of 1 on its target end.
- These multiplicities may be assumed if not shown on a diagram.
- To avoid confusion, any multiplicity other than the default should always be shown on a diagram.
- Unit and QuantityKind definitions
- Unit and QuantityKind elements are defined using a rectangular box notation similar to a block, in which only the “unit” or “quantityKind” stereotype keyword, the name of the Unit or QuantityKind, and optionally the “quantityKind” property value of a ..
- Even though the base metaclass of Unit and QuantityKind is InstanceSpecification, the name of a QuantityKind or Unit is not underlined, and no other graphical elements of a UML InstanceSpecification may be shown.
- The optional “quantityKind” property of a Unit and the “quantityKind” and/or “unit” properties of a ValueType are specified using standard stereotype property notations, which must refer by name to a QuantityKind or Unit which has already been defined ..
- A sample set of predefined quantity kinds and units is given in Annex C, Section C.4.
- Property-specific type
- 8.3.1.2 Internal Block Diagram
- An internal block diagram is based on the UML composite structure diagram, with restrictions and extensions as defined by SysML.
- Default multiplicities
- Property types
- Four general categories of properties of blocks are recognized in SysML: parts, references, value properties, and constraint properties.
- (See Section 8.3.2.2, “Block, for definitions of these property types.)
- A part or value property is always shown on an internal block diagram with a solid-outline box.
- A reference property is shown by a dashed-outline box, consistent with UML.
- Ports are special cases of properties, and have a variety of notations as defined in Chapter 10, Ports and Flows.
- Constraint properties and their parameters also have their own notations as defined in Chapter 11, Constraint Blocks.
- Block reference in diagram frame
- Compartments on internal properties
- SysML permits any property shown on an internal block diagram to also show compartments within the property box.
- These compartments may be given standard or user-customized labels just as on block definitions.
- All features shown within these compartments must match those of the block or value type that types the property.
- For a property-specific type, these compartments may be used to specify redefined or additional features of the locally defined type.
- An unlabeled compartment on an internal property box is by default a structure compartment.
- The label of any compartment shown on the property box that displays contents belonging to the type of the property is shown with a colon character (“:”) preceding the compartment label.
- SysML permits any property shown on an internal block diagram to also show compartments within the property box.
- Compartments on a diagram frame
- Property path name
- Nested connector end
- Property-specific type
- Initial values compartment
- 8.3.1.1 Block Definition Diagram
- 8.3.2 Stereotypes
- 8.3.2.1 Binding Connector
- A Binding Connector is a connector which specifies that the properties at both ends of the connector have equal values.
- If the properties at the ends of a binding connector are typed by a ValueType, the connector specifies that the instances of the properties must hold equal values, recursively through any nested properties within the connected properties.
- If the properties at the ends of a binding connector are typed by a Block, the connector specifies that the instances of the properties must refer to the same block instance.
- As with any connector owned by a SysML Block, the ends of a binding connector may be nested within a multi-level path of properties accessible from the owning block.
- The NestedConnectorEnd stereotype is used to represent such nested ends just as for nested ends of other SysML connectors.
- 8.3.2.10 ValueType
- Attributes
- Constraints
- Description
- A ValueType defines types of values that may be used to express information about a system, but cannot be identified as the target of any reference.
- Since a value cannot be identified except by means of the value itself, each such value within a model is independent of any other, unless other forms of constraints are imposed.
- Value types may be used to type properties, operation parameters, or potentially other elements within SysML.
- SysML defines ValueType as a stereotype of UML DataType to establish a more neutral term for system values that may never be given a concrete data representation.
- For example, the SysML “Real” ValueType expresses the mathematical concept of a real number, but does not impose any restrictions on the precision or scale of a fixed or floating-point representation that expresses this concept.
- 8.3.2.2 Block
- Description
- A Block is a modular unit that describes the structure of a system or element.
- SysML blocks provide a general-purpose capability to describe the architecture of a system.
- SysML does not restrict the kind of system or system element that may be described by a block.
- Connectors owned by SysML blocks may be used to define relationships between parts or other properties of the same containing block.
- SysML excludes variations of associations in UML in which navigable ends can be owned directly by the association.
- SysML establishes four basic classifications of properties belonging to a SysML Block or ValueType.
- On a block definition diagram, a part property is shown by a black diamond symbol on an association.
- SysML also supports properties with shared aggregation, as shown by a white diamond symbol on an association.
- In addition to the form of default value specifications that SysML supports on properties of a block (with an optional “=” <value-specification> string following the rest of a property definition), SysML supports an additional form ..
- Context-specific values are represented in the SysML metamodel by means of the InstanceValue subtype of UML ValueSpecification.
- If a property belonging to a block has a specification of initial values for any of the properties belonging to its type, then the default value of that property must be a UML InstanceValue element.
- This element must reference a UML InstanceSpecification element created to hold the initial values of the individual properties within its usage context.
- The instance specification must be unnamed and owned by the same package that owns the outermost containing block for which the initial values are being specified.
- Selected slots of the referenced instance specification must contain value specifications for the individual property values specified in a corresponding initialValues compartment.
- If a value of a property is shown by a nested property box with its own initialValues compartment, then the slot of the instance specification for the containing property must hold a new InstanceValue element.
- Selected slots of the instance specification referenced by this value must contain value specifications for any nested initial values, recursively through any number of levels of nesting.
- A tree of instance values referencing instance specifications, each of which may in turn hold slots carrying instance values, must exist until self-contained value specifications are reached at the leaf level.
- Attributes
- Constraints
- Demonstration: contents of: 8.3.2.2 Block as hierarchical hyperlink tree
- Description
- 8.3.2.3 ConnectorProperty
- Attributes
- Constraints
- Description
- Connectors can be typed by association classes that are stereotyped by Block (association blocks, see Section 8.3.2.6, “ParticipantProperty).
- These connectors specify instances of the association block created within the instances of the block that owns the connector.
- The values of a connector property are instances of the association block created due to the connector referred to by the connector property
- A connector property can optionally be shown in an internal block diagram with a dotted line from the connector line to a rectangle notating the connector property.
- The keyword «connector» before a property name indicates the property is stereotyped by ConnectorProperty.
- 8.3.2.4 DistributedProperty
- Constraints
- DistributedProperty is a stereotype of Property used to apply a probability distribution to the values of the property.
- Specific distributions should be defined as subclasses of the DistributedProperty stereotype with the operands of the distributions represented by properties of those stereotype subclasses.
- A sample set of probability distributions that could be applied to value properties is given in Annex C, Section C.6, “Distribution Extensions.”
- 8.3.2.5 NestedConnectorEnd
- 8.3.2.6 ParticipantProperty
- Attributes
- Description
- The Block stereotype extends Class, so it can be applied to any specialization of Class, including Association Classes.
- These are informally called “association blocks.”
- An association block can own properties and connectors, like any other block.
- Each instance of an association block can link together instances of the end classifiers of the association.
- To refer to linked objects and values of an instance of an association block, it is necessary for the modeler to specify which (participant) properties of the association block identify the instances being linked at which end of the association.
- The value of a participant property on an instance (link) of the association block is the value or object at the end of the link corresponding to this end of the association.
- Participant properties can be the ends of connectors owned by an association block.
- The association block can be the type of multiple other connectors to reuse the same internal structure for all the connectors.
- The keyword «participant» before a property name indicates the property is stereotyped by ParticipantProperty.
- The types of participant properties can be elided if desired. They are always the same as the corresponding association end type.
- 8.3.2.7 PropertySpecificType
- Constraints
- The PropertySpecificType stereotype is automatically applied to the classifier that types a property with a propertyspecific type.
- This classifier can contain definitions of new or redefined features that extend the original classifier referenced by the property-specific type.
- Classifiers with the PropertySpecificType stereotype are owned by the block that owns the property that has the propertyspecific type.
- A classifier with this stereotype must specialize at most a single classifier that was referenced as the starting classifier of the property-specific type.
- If there is no starting classifier (which occurs if no existing name is specified as the starting type of a property-specific type), then a classifier with the stereotype applied has no specialization relationship from any other classifier.
- 8.3.2.8 QuantityKind
- 8.3.2.9 Unit
- *AbstractReferenceProperty
- *BlockProperty
- *Dimension
- *PartProperty
- *ReferenceProperty
- *SharedProperty
- *ValueProperty
- 8.3.2.1 Binding Connector
- 8.3.3 Model Libraries
- 8.3.3.1 Boolean
- 8.3.3.2 Complex
- Attributes
- Description
- A Complex value type represents the mathematical concept of a complex number.
- A complex number consists of a real part defined by a real number, and an imaginary part defined by a real number multiplied by the square root of -1.
- Complex numbers are used to express solutions to various forms of mathematical equations.
- 8.3.3.3 Integer
- 8.3.3.4 Number
- 8.3.3.5 Real
- 8.3.3.6 String
- 8.3.1 Diagram Extensions
- 9 Ports and Flows
- 10 Constraint Blocks
- Part III - Behavioral Constructs
- 11 Activities
- 11.3 UML Extensions
- 11.3.2 Stereotypes
- 11.3.3 Model Libraries
- 11.3.3.1 ControlValue
- Constraints
- Description
- The ControlValue enumeration is a type for treating control values as data (see Section 11.3.2.2) and for UML control pins.
- It can be used as the type of behavior and operation parameters, object nodes, and attributes, and so on.
- The possible runtime values are given as enumeration literals.
- Modelers can extend the enumeration with additional literals, such as suspend, resume, with their own semantics.
- The disable literal means a termination of an executing behavior that can only be started again from the beginning (compare to suspend).
- The enable literal means to start a new execution of a behavior (compare to resume).
- 11.3.3.1 ControlValue
- 11.3 UML Extensions
- Part IV - Crosscutting Constructs
- 12 Interactions
- 13 State Machines
- 14 Use Cases
- 15 Allocations
- 15.3 UML Extensions
- 15.3.2 Stereotypes
- 15.3.2.1 Allocate(from Allocations)
- Constraints
- Description
- Allocate is a dependency based on UML::abstraction.
- It is a mechanism for associating elements of different types, or in different hierarchies, at an abstract level.
- Allocate is used for assessing user model consistency and directing future design activity.
- It is expected that an «allocate» relationship between model elements is a precursor to a more concrete relationship between the elements, their properties, operations, attributes, or sub-classes.
- Allocate is a stereotype of a UML4SysML::Abstraction which is permissible between any two NamedElements.
- It is depicted as a dependency with the “allocate” keyword attached to it.
- Allocate is directional in that one NamedElement is the “from” end (no arrow), and at least one NamedElement is the “to” end (the end with the arrow).
- The following paragraphs describe types of allocation that are typical in systems engineering.
- Behavior allocation relates to the systems engineering concept segregating form from function. [..]
- This concept requires independent models of “function” (behavior) and “form” (structure), and a separate, deliberate mapping between elements in each of these models.
- It is acknowledged that this concept does not support a standard object-oriented paradigm, nor is this always even desirable.
- Experience on large scale, complex systems engineering problems have proven, however, that segregation of form and function is a valuable approach.
- In addition, behavior allocation may also include the allocation of Behaviors to BehavioralFeatures of Blocks, e.g., Operations.
- Flow allocation specifically maps flows in functional system representations to flows in structural system representations.
- Flow between activities can either be control or object flow. [..]
- The figures in the Usage Examples show concrete syntax for how object flow is mapped to connectors on Activity Diagrams.
- Allocation of control flow is not specifically addressed in SysML, but may be represented by relating an ItemFlow to the Control Flow using the UML relationship InformationFlow.realizingActivityEdge.
- Note that allocation of ObjectFlow to Connector is an Allocation of Usage, and does NOT imply any relation between any defining Blocks of ObjectFlows and any defining associations of connectors.
- The figures in the Usage Examples illustrate an available mechanism for relating the objectNode from an activity diagram to the itemFlow on an internal block diagram.
- ItemFlow is discussed in Chapter 9, Ports and Flows.
- Pin to Port allocation is not addressed in this release of SysML.
- Structure allocation is associated with the concept of separate “logical” and “physical” representations of a system. [..]
- It is often necessary to construct separate depictions of a system and define mappings between them.
- For example, a complete system hierarchy may be built and maintained at an abstract level.
- In turn, it must then be mapped to another complete assembly hierarchy at a more concrete level.
- The set of models supporting complex systems development may include many of these levels of abstraction.
- This specification will not define “logical” or “physical” in this context, except to acknowledge the stated need to capture allocation relationships between separate system representations.
- 15.3.2.2 Allocated(from Allocations)
- 15.3.2.3 AllocateActivityPartition(from Allocations)
- 15.3.2.1 Allocate(from Allocations)
- 15.3.2 Stereotypes
- 15.3 UML Extensions
- 16 Requirements
- 17 Profiles & Model Libraries
- Part V - Annexes
- Annex A: Diagrams (informative)
- Annex B: Sample Problem (informative)
- Annex C: Non-normative Extensions (informative)
- Annex D: Model Interchange
- Annex E: Requirements Traceability (informative)
- Annex F: Terms and Definitions (informative)
- Packages (SysML)
- Webel IT Australia: SysML *Analysis Stereotypes
- OMG MARTE
- OMG ManTIS
- OMG Robotics
- OMG Space DTF
- OMG UML Testing Profile (UTP)
- Object Management Group Technical Meeting, Brussels 2007
- Object Management Group Technical Meeting, Washington DC 2008
- Galleries index: Science
- Gallery: Science: examples
- Scientific instruments
- Radiotelescopes
- The Molonglo Observatory Synthesis radioTelescope (MOST) in UML & Java (and FORTRAN)
- Gallery: a UML Parsing Analysis of an analysis of image formation in the MOST radiotelescope (from 2005)
- Gallery: the MOST radiotelescope in Java and UML
- Honours thesis (1988): "An analysis of image formation by MOST (Molonglo Observatory Synthesis radioTelescope)": figures, scans, and UML models
- Gallery: MOST rotational aperture radiosynthesis figures (1988)
- Figure 1: MOST radiotelescope "skymap" from observation of a strong point source at field centre
- Figure 2: A diagram of MOST with the numbering system used in this thesis report (1988)
- Figure 3: MOST radiotelescope: A diagram of the coordinate system used in the report (1988)
- Figure 5: The MOST radiotelescope centre fan-beam with field centre at meridian (from 1988)
- Figure 10: the MOST radiotelescope synthesised beam
- Gallery: scans of (some of) the MOST thesis report from 1988
- Gallery: MOST rotational aperture radiosynthesis figures (1988)
- On Dr Darren's involvement with the MOST radiotelescope
- MOST: Java3D animations
- The Molonglo Observatory Synthesis radioTelescope (MOST) in UML & Java (and FORTRAN)
- Neutron Beam Instruments (NBIs)
- Gallery: Port-based systems engineering of block models for control and simulation of Neutron Beam Instruments of the OPAL research reactor using UML/SysML (from 2007, online extracts)
- Figure 01: Convention and notation for Class/Interface pairs and associated wrapper Component.
- Figure 02: Flowport notation for mapping UML2 to Java
- Figure 03: Example: neutron beam instrument flowports and blocks for UML2
- Figure 04: ExampleBlock convention for block wrapper components and organisation of engineering elements
- Figure 05: Example: UML2 composite structure diagram (systems engineering view) of a fictitious neutron beam conditioning bunker.
- Figure 06: Example: wrapped class diagram (software engineering view) of a fictitious neutron beam conditioning bunker
- Figure 07: Model: Top-level UML2 composite structure diagram (systems engineering view) for the Platypus Reflectometer
- Figure 08: Model: Bunker shield assembly for the the Platypus reflectometer as UML2 composite structure diagram with flowport notation.
- Figure 09: Model: bunker shield assembly for the Platypus reflectometer as "wrapped block" class diagram.
- Figure 10: Model: UML2 composite structure diagram for the monochromation beam stage of the neutron diffractometers of the OPAL NBIs.
- Figure 11: Model: UML2 composite structure diagram of the monochromator assembly
- Figure 12: Model: UML2 composite structure diagram of the monochromator stage assembly with motorised goniometer rotation, tilt, and translation stages, which are driven by encoded devices.
- Figure 13: Model: wrapped block class diagram (software engineering view) for the entire monochromation beam ("logical") stage.
- Figure 14: SWT TableTree ModelClient showing an instance of the Platypus reflectometer model.
- Figure 15: Simplified SysML version of the Platypus neutron reflectometer model.
- Meeting of the NeXus International Advisory Committee (NIAC), 2006
- Meeting of the NeXus International Advisory Committee (NIAC), 2008
- Gallery: Port-based systems engineering of block models for control and simulation of Neutron Beam Instruments of the OPAL research reactor using UML/SysML (from 2007, online extracts)
- Particle colliders
- Radiotelescopes
- Data analysis and visualisation
- Symbolic Algebra zone
- Cognitive Science zone
- Biology zone
- Astrophysics & Astronomy zone
- Synthesis zone
- Mathematics zone
- Media
- Punctuation (English)
- Quotations
- Albert Einstein: some favourite quotes
- Quote: Albert Einstein: "Everything should be made as simple as possible, but not simpler."
- Quote: Albert Einstein: "Great spirits have often encountered violent opposition from weak minds."
- Quote: Albert Einstein: "If we knew what it was we were doing, it would not be called research, would it?"
- Quote: Albert Einstein: "If you are out to describe the truth, leave elegance to the tailor."
- Quote: Albert Einstein: "Imagination is more important than knowledge."
- Quote: Albert Einstein: "So long as they don't get violent, I want to let everyone say what they wish, for I myself have always said exactly what pleased me."
- Quote: Albert Einstein: "Whoever undertakes to set himself up as a judge of Truth and Knowledge is shipwrecked by the laughter of the gods."
- Albert Einstein: some favourite quotes
- Software Engineering references
- Web Development Reference
- Cascading Style Sheet (CSS) reference
- Email Clients: usage, compatibility, stats, relative popularity, experiences, opinions
- JavaScript
- PHP zone
- Search Engine references (and trivia)
- Web "safe" fonts
- Web Browsers: usage, compatibility, stats, relative popularity, experiences, opinions
- Web fonts (loadable, linkable, or embedded): beyond the "safe" 10
Banner Links
hot topics
Art
A vocabulary of art terms.
- animation (3)
- accelerometer art (24)
- accelerometer music (24)
- body music (2)
- gestural music (1)
- PLAY (1)
- Simpsons (5)
- slideshow (1)
- synthesised music (1)
- uml (1)
- uml parsing analysis (1)
- undefined (1)
- xmas (1)
- music (101)
- air music (95)
- air DJ (4)
- air drum (1)
- air drums (14)
- air guitar (6)
- air scratching (4)
- air synth (9)
- air DJ (4)
- electroacoustic music (2)
- sample (1)
- sound installation (2)
- sound space (1)
- sound space (1)
- air music (95)


- youtube (2)

- light show (49)
Image Galleries
Language
- body language (1)
- gesture (4)
- JavaScript (1)
- parsing (1)
- taxonomy (1)
Media
Newsletter
Science
A vocabulary of scientific terms.
- acceleration (35)
- additive colour (5)
- AM (1)
- amplitude modulation (9)
- amplitude variation (2)
- asteroid (1)
- atom (1)
- audio (1)
- beam (2)
- beam instruments (2)
- biofeedback (2)
- bit depth (1)
- bit rate (1)
- Bragg physics (3)
- brain (1)
- brehmstrahlung (1)
- Cartesion coordinate system (1)
- center (1)
- chemistry (1)
- circle (4)
- circular polarisation (1)
- cognitive science (1)
- collection (1)
- colour (1)
- computational physics (1)
- conic (3)
- conic section (2)
- control systems (1)
- data analysis (3)
- data visualisation (1)
- dB (2)
- dBFS (2)
- dBu (2)
- dBVU (2)
- decibel (2)
- deconvolution (1)
- diagonal (1)
- diffractometer (4)
- directrix (1)
- distance (1)
- Earth (1)
- eccentricity (1)
- ecology (2)
- edge (1)
- Education (4)
- electromagnetism (2)
- electron (4)
- element (1)
- ellipse (3)
- energy (1)
- environment (2)
- equal tempered tuning (1)
- equilateral (1)
- exponent (1)
- field (1)
- Field (physics) (1)
- focus (1)
- frequency (3)
- frequency modulation (2)
- function (1)
- general relativity (1)
- geometry (5)
- graph (1)
- group (2)
- hci (1)
- HERA (4)
- holarchy (1)
- holon (2)
- human synthesizer (1)
- hyperbola (2)
- IT Training (1)
- jupiter (1)
- Lagrangian (1)
- Lie group (1)
- lifetime (1)
- light (1)
- line (3)
- locus (2)
- logical (1)
- LUFS (1)
- Mars (2)
- mathematics (21)
- matrices (1)
- measurement (1)
- mechanics (2)
- mercury (1)
- metrology (1)
- monochromation (4)
- moon (1)
- movement therapy (4)
- muon (1)
- muon science (1)
- neptune (1)
- neutron scattering (6)
- neutron science (8)
- non-tactile (1)
- nuclear physics (2)
- nuclear reactor (4)
- nuclei (1)
- number (1)
- OPAL (1)
- OPAL research reactor (10)
- operator (1)
- optics (1)
- oscillation (3)
- parabola (2)
- particle physics (58)
- neutron beam instrument (22)
- particle (8)
- neutron (4)
- neutron (4)
- particle collider (11)
- neutron beam instrument (22)
- physic (1)
- physics (38)
- applied physics (1)
- astronomy (22)
- radioastronomy (17)
- supernova (2)
- radioastronomy (17)
- astrophysics (2)
- radiophysics (4)
- scattering physics (5)
- applied physics (1)
- plane (1)
- plane figure (2)
- planet (1)
- planets (1)
- Platypus Reflectometer (5)
- plotting (1)
- pluto (1)
- point (3)
- polarisation (1)
- polygon (4)
- positron (1)
- primary colours (5)
- quadratic (1)
- quadric surface (1)
- quantity (4)
- radio (1)
- radiosynthesis (12)
- radiotelescope (42)
- MOST (19)
- MOST (19)
- radius (1)
- reflectometry (2)
- regular polygon (1)
- relation (1)
- research reactor (2)
- response (1)
- rhombus (1)
- sample rate (1)
- saturn (1)
- science (4)
- Scientific instruments (5)
- segment (1)
- set (1)
- shape (4)
- solar system (2)
- space (2)
- space (mathematics) (2)
- sports performance measurement (1)
- sports science (2)
- square (1)
- star (1)
- statistics (1)
- storage ring (2)
- stress-energy-tensor (1)
- sun (1)
- synaesthesia (1)
- tensor (1)
- time (1)
- tomography (1)
- Training (4)
- Trapezium (1)
- Triangle (1)
- tutorial (2)
- unit (2)
- units (3)
- uranus (1)
- value (3)
- venus (1)
- vertex (1)
- visua (1)
- vitruvian man (1)
- x-ray (2)
- x-ray science (1)
- xray (1)
Technology
tech vocabulary
- bending sensor (1)
- computing (417)
- computer graphics (43)
- 3D (3)
- 4D (2)
- graphics editing (10)
- network graphing (12)
- plotting (3)
- Gnuplot (1)
- Gnuplot (1)
- PV-WAVE (1)
- screencasting (3)
- typesetting (1)
- 3D (3)
- computing language (90)
- CSS (11)
- declarative language (1)
- functional language (2)
- graphical language (10)
- imperative language (1)
- interactive data language (2)
- JSON (1)
- JSON (1)
- object-oriented language (8)
- procedural language (6)
- prototype-based programming (1)
- query language (13)
- SQL (12)
- SQL (12)
- report language (1)
- scripting language (14)
- JavaScript (3)
- Tcl (3)
- Tcl/Tk (1)
- Tcl/Tk (1)
- JavaScript (3)
- CSS (11)
- transformation (1)
- C (8)
- C++ (11)
- Qt (5)
- Qt (5)
- computer graphics (43)

- database schema (2)
- Hibernate (7)
- HQL (1)
- HQL (1)
- mysql (12)
- object-relational mapping (13)
- persistence (3)
- RDBMS (10)
- transaction management (1)



- CORBA (5)
- event heap (1)
- event space (1)
- object space (2)
- RPC (1)
- SOAP (4)






- Controller (52)
- Wiimote (52)
- Wiimote (52)
- gestural control (3)
- HCI (2)
- air typing (2)

- JCL (1)

- Eclipse IDE (28)
- Eclipse (7)
- SWT (2)
- SWT (2)
- Eclipse Modeling Framework (EMF) (19)
- EMF (8)
- EMF (8)
- Eclipse (7)







- control application (1)
- master-slave (1)
- SICS (4)

- data acquisition (16)



- Service Data Objects (4)
- SDO (3)
- SDO (3)

- design patterns (6)
- model view controller (2)
- MVC (3)
- model view controller (2)

- strategy reuse (1)

- project management (2)
- requirement (3)
- reverse-engineering (8)
- testing (5)
- test (1)
- validation (1)
- test (1)

- GIMP (3)
- image manipulation (1)
- image processing (3)

- tubigrip (1)

- software-engineering (83)
- visual programming (53)
- Agilent VEE (1)
- HP VEE (1)
- LabVIEW (1)
- patch editor (3)
- patch programming (36)
- Visual Basic (1)
- visual language (2)
- block programming (4)
- blocks (2)
- blocks (2)
- Agilent VEE (1)
- visual programming (53)
- wrapper (10)
- AOP (1)
- application programming interface (10)
- API (6)
- API (6)
- CASE (2)
- component-oriented (1)

- LED (20)
- sensor (124)
- sensor suit (7)
- transducer (114)
- accelerometer (111)
- accelerometer (111)
- sensor suit (7)



- scientific instrument (9)
- musical instrument (328)
- air instrument (324)
- air music (6)
- air drums (2)
- air guitar (1)
- Drancing (249)
- Drancel (38)
- DranceWare (66)
- Drancel (38)
- air synth (2)
- air music (6)
- digital musical instrument (4)
- MIDI (2)
- MIDI (2)
- air instrument (324)


- ISO (1)

- HTTP (1)
- HTTP web server (2)
- web site (12)


- metamodel (3)
- modelling language (631)
- Modelica (1)
- Systems Modeling Language (159)
- SysML (124)
- SysML (124)
- Unified Modeling Language (466)
- UML (429)
- MagicDraw UML (82)
- MD SysML (18)
- MD SysML (18)
- meta-object facility (4)
- MOF (3)
- MOF (3)
- Rational Rose (2)
- RSA (1)
- RSA (1)
- MagicDraw UML (82)
- UML (429)
- UML activity diagram (2)
- UML class diagram (5)
- UML composite structure diagram (9)
- Modelica (1)




- NeXML (2)

- OMG (1)

- DOM (5)


- access control (1)

- DEC (1)
- GNU (2)
- Mac OS X (22)
- Microsoft Windows (13)
- Windows 2000 (1)
- Windows 2003 (1)
- Windows 95 (1)
- Windows 98 (1)
- Windows ME (1)
- Windows NT (1)
- Windows Vista (1)
- Windows XP (1)
- Windows 2000 (1)
- MS Windows (1)
- MS-DOS (1)
- MVS (1)
- Sun Solaris (1)
- TSO (1)
- UNIX (22)
- VAX (1)
- VMS (1)
- windowing system (3)

- electron (1)
- particle collider (technology) (1)
- positron (1)
- proton (1)

- Java (379)
- EJB (5)
- Enterprise JavaBeans (12)
- Java EE (92)
- Java Foundation Classes (1)
- JFC (1)
- JFC (1)
- Java FX (2)
- Java Native Interface (4)
- JNI (3)
- JNI (3)
- Java Swing (2)
- Java3D (30)
- j3d (1)
- j3d (1)
- JavaBeans (7)
- JavaServer Faces (22)
- JSF (12)
- JSF (12)
- JavaServer Pages (22)
- JSP (15)
- JSP (15)
- JavaSpace (1)
- JavaSpaces (1)
- JDBC (1)
- JDO (6)
- JDOQL (1)
- JDOQL (1)
- JINI (2)
- JMS (1)
- JSyn (19)
- JUNG (17)
- JVM (1)
- POJO (2)
- remote method invocation (4)
- RMI (2)
- RMI servlet (1)
- RMI (2)
- servlet (16)
- servlet container (2)
- servlets (6)
- servlet container (2)
- Swing (7)
- AWT (2)
- EJB (5)
- markup language (124)
- document markup language (2)
- extensible markup language (111)
- XML (39)
- XML database (3)
- XML Schema (32)
- XPath (3)
- XQuery (1)
- XSD (15)
- XSL Transformations (16)
- XML (39)
- document markup language (2)
- LaTeX (4)
- Lyx (1)
- Lyx (1)
- TeX (2)
- WSDL (2)

- OCL (4)



- access control (1)

- digital signal processing (27)
- HURON (1)
- sample (4)
- schmidt trigger (2)
- variable frequency oscillator (7)
- VFO (5)
- channel operator (2)
- CHOP (1)
- CHOP (1)
- HURON (1)





- software application (199)
- chat client (1)
- Skype (1)
- Skype (1)
- document processor (1)
- Google Earth (1)
- measurement application (2)
- office suite (12)
- chat client (1)
- presentation software (3)
- presentation (1)
- presentation (1)
- rapid application development environment (2)
- application server (2)
- browser (14)
- Cascading Style Sheets (12)
- stylesheets (2)
- stylesheets (2)
- Cascading Style Sheets (12)


- interoperability (1)
- loose coupling (1)
- service-orientation (2)
- SOA (1)
- SOA (1)
- service-oriented architecture (2)
- OSOA (1)
- OSOA (1)

- software development process (29)
- design (6)
- feature (4)
- feature-driven development (2)
- feature-oriented development (1)
- issue tracking (15)
- JIRA (13)
- JIRA (13)
- quality assurance (1)
- design (6)
- bug reporting (1)
- bugs (1)

- Doxygen (1)


- spatialized sound (1)
- spreadsheets (4)
- Excel (1)
- Excel (1)

- Maple (8)
- Mathematica (5)
- mathematics worksheets (1)
- MATLAB (4)
- Simulink (1)
- Simulink (1)

- FM synthesis (1)
- gestural synthesis (23)
- PureData (145)
- GEM (69)
- GEM (69)
- real-time synthesis (66)
- video synthesis (43)
- AM synthesis (1)

- requirements language (3)
- systems integration (1)
- systems language (1)



- graphical user interface (23)
- GUI (4)
- WYSIWYM (1)
- X Windows (1)
- air typing (2)
- widgets (1)
- widget toolkit (1)
- widget toolkit (1)
- GUI (4)


- QuickTime (3)
- mov (1)
- mov (1)
- video editing (4)










































































































































































































































































































































































- scene graph (1)


- Oracle ADF (4)
- Swing ADF Faces (1)
- Swing ADF Faces (1)
- Spring Application Framework (1)

- limiter (1)
- mp3 (2)
- virtual instrumentation (1)
- audio editing (3)
- audio sample (3)
- audio server (1)
- audio synthesis (64)
- ambisonics (3)
- ambisonics (3)
- compressor (1)



- web application framework (9)
- Struts (1)
- Struts (1)
- web applications (9)
- web authoring (5)
- web language (3)
- web server (7)
- GlassFish (3)
- portlets (1)
- Apache Tomcat (3)
- GlassFish (3)
- web services (11)
- world wide web (1)


Related sites
- Webel's video channel on Vimeo
- Webel's photo channel on SmugMug
- Webel's Drupal7 info site
- Webel's Drupal8 info site
- The GreenSoft company site
- The GreenDesk tutorial site
- The GreenDesk video channel on Vimeo
- The GreenSoft Twitter stream
Browse by content type
Keywords
Content Management System
SysML Internal Block Diagram
patch programming
OPAL research reactor
XML
UML Component
website
object-relational mapping
Java
real-time synthesis
Drancing
JUNG
Java EE Server
gestural synthesis
particle physics
digital graphics
sound engineering
distributed computing
port-based engineering
DranceWare
database
SQL
audio synthesis
light show
UML1.x
XSD
graphics editing
signal processing
symbolic algebra
LED
UML Parsing Analysis
Java3D
UML2
visuals
Enterprise Java
air music
screenshot
graphical user interface
air drums
video synthesis
Drancel
JavaServer Faces
Cascading Style Sheets
SysML Block
SysML
synthesis
Wiimote
ontology
PureData
ObjectDB
Mac OS X
GEM
Eclipse Modeling Framework (EMF)
visualisation
JIRA
Shibboleth
particle collider
systems engineering
web site
JSF
accelerometer music
Systems Modeling Language
mysql
XML Schema
MD SysML
simulation
Enterprise JavaBeans
enterprise architecture
accelerometer art
JSP
CMS
Unified Modeling Language
Java EE
web services
radiosynthesis
radiotelescope
mathematics
network graphing
radioastronomy
CSS
Web Ontology Language (OWL)
acceleration
JSyn
PHP
object-orientation
UML
Drupal
animation
web development
Wii
neutron beam instrument
air instrument
Drupal7
audio engineering
accelerometer
MOST
MagicDraw UML
Java EE Container
RDBMS
wrapper