http://www.websequencediagrams.com/

You just simply type the flow and it does the rest for you. Make sure to follow the correct syntax.

I have been using this for couple of days and my productivity has shot up 50%. I dont have to worry about trying to position the Object Lifeline or Message or Activation Shapes in visio. Truly a great product.

I 'd like to give some basics about UML diagrams.

1)Classes
Figure shows the simplest form of class diagram. The class named Dialler is represented as a simple rectangle. This diagram represents nothing more than the code shown to its right.

2)Association

Associations between classes most often represent instance variables that hold references to other objects.

3)Multiplicity

The number near the arrowhead represents the number of objects that connected to the other associate. In Figure above we saw that fifteen Button objects were connected to the Phone object.

In figure below,A Phonebook is connected to many PhoneNumber objects. The star means many. In Java this is most commonly implemented with a Vector, a List, or some other container type.

4)Inheritence

In UML all arrowheads point in the direction of source code dependency. Since it is the SalariedEmployee class that mentions the name of Employee, the arrowhead points at Employee. So, in UML, inheritance arrows point at the base class.

5) Interface

UML has a special notation for the kind of inheritance used between a Java class and a Java interface. It is shown, in Figure, as a dashed inheritance arrow.

biasanya dalam membuat desain, klo dia programnya OOP brarti kan make UML, standarnya diagram yang dipake ada 4, yaitu usecase diagram, activity diagram, class diagram dan sequence diagram

dalam satu life cycle pengembangan aplikasi, pada tahap analisa kebutuhan (requirement gathering) kita menghasilkan diagram usecase dan activity

pada tahap desain, kita menghasilkan class diagram dan sequence diagram

lalu mulailah tahap coding, yg dipake acuan oleh para programmer ntar harusnya class diagram dan sequence diagram (2 itu udah cukup, klo ditambahin diagram lain y malah bagus)

kapan2 nulis ttg diagram2 deh (entah postingan keberapa ntar)

correct me if i wrong

 http://www.codeproject.com/KB/aspnet/SoftArch5.aspx

 http://odl-skopje.etf.ukim.edu.mk/uml-help/

Now that all is ready, I know that probably the time is not enough for GSoC deadline to complete all that I would like to complete (even if I'll try to do my best), that would be:

• Externalise data model from cmyk.js
• Create and package a better data model for rules handling (with some GUI hacking I could let it work in few time after creating it)
• Refactor Osmarender Frontend (the GUI section) code
• Externalise and dynamic loading some GUI resources (like the various panels)
• Refactor some controls (mainly those that edit CSS properties) as Dojo widgets
• If time permits, start using Dojo templating system for some GUI resources
• Create all packages ready for release

The hardest thing to do would be to write and get to work the refined data model for rules handling. This is because, after a quick refresh of my Osmarender rules knowledge, I've produced the rough sort-of-UML model shown above (thank to argouml), which represents needed classes, inheritances, attributes and types. That explains clearly how difficult will be a proper refactoring, at least to get it to work for GSoC deadline without too much loose ends. Obviously I don't want to risk to break something now. :)

So, what I'm doing now? I'm using a mixed "top-down/bottom-up" stategy. I've already refactored some data models used by cmyk.js (1st point) and I'm just starting to externalise and dynamic loading GUI resources for Osmarender Frontend (4th point). This is going to be a step by step process, refactoring the code and re-testing the GUI any time, for every bit, to see if some regression bug appears. It would be quite slow, but, IMO, too much needed to have a maintainable and more flexible code for future improvements.

In the meantime, I'll begin to prepare Osmarender Frontend's directory in SVN for release.

Java fejlesztőket (junior/senior)

keres futó projektjeikhez, azonnali belépéssel.

Alvállalkozói státusz is szóba jöhet!

Követelmények:

• Java programozási nyelv és J2EE platform alapos ismerete, de legalább 1-2 éves fejlesztői tapasztalat.
• Objektum orientált tervezési és programozási ismeretek, UML gyakorlat.
• Erős projekt alapú gondolkodás, célorientáltság.
• Az alábbi technológiák ismerete:
• Spring
• Hibernate
• Web Services
• Drools
• JBPM
• Rhino
• Szakmai angol nyelv ismerete.

Előny:

• Banki alkalmazások terén szerzett tapasztalat.
• JavaScript és CSS ismeretek.

laszlo_spiller@kellyservices.hu

este é o protótipo do diagrama de classes para meus projetos de engines (apenas a parte de video), o nome SGE(Simple Game Engine) criei porque o projeto para jogos de DS e para PC (que vai usar Lua com C++) tem a mesma teoria, o que vai mudar é a implementação.

A idéia aqui é criar um gerenciador de sistemas, sendo estes sistemas o video, som e o próprio jogo será um sistema. A engine vai ser orientada a cenas, a idéia são jogos simples em 2D. Esse é o modelo para a parte de video apenas.

idéias, correções e comentários são muito bem aceitos.

ciao

• Vista de Casos de Uso: que contiene requisitos desarrollados en las restantes vistas.
• Vista Lógica: Muestra la estructura estática del sistema.
• Vista Física: Muestra el despliegue de la aplicación en la red de computadoras.
• Vista de Procesos: Muestra los hilos y procesos de ejecución así como la comunicación entre estos.
• Vista de Desarrollo: Muestra la estructura en modelos del código del sistema.

Estas vistas se presenta tradicionalmente en una figura de cuatro cajas con un ovalo central que representa al modelo de casos de uso. Dicho gráfico no es UML pero al ser tan conocido no puedo menos que incluirlo en el post. La siguiente figura corresponde a esta imagen de la que hablo:

Fig. 1 - Diagrama simple del enfoque 4+1 vistas.

El enfoque 4+1 vistas fue desarrollado originalmente por Philippe Kruchten en 1995, el artículo original puede ser encontrado en la Internet en: http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf.

De acuerdo al Sr. Kruchten, las distintas vistas del enfoque responden a las necesidades de las distintas partes interesadas: clientes, programadores, administradores, etc. Para cada uno de estos, se presenta una visión resumida del sistema con la información que requieren para satisfacer sus necesidades.

Es así que la vista de desarrollo le dice al programador como iniciar y organizar su código; la vista física ayuda a los administradores de sistemas a decidir la infraestructura que se ha de dedicar al sistema; la vista de procesos es útil para realizar análisis de integridad y tomar decisiones de integración con otros sistemas; finalmente, siempre de acuerdo con el Sr. Kruchten, la vista lógica le sirve a los usuarios y clientes a visualizar la funcionalidad que el sistema les provee.

Este enfoque es uno de los más extendidos en la literatura, sin embargo su aplicación es de alcance limitado en los tiempos modernos, donde las aplicaciones tradicionales han dejado su lugar a sistemas basados en Web. Es entonces un enfoque digno de estudio aunque es probable que en nuestros proyectos sigamos otras aproximaciones para la organización y presentación de nuestros modelos.

El siguiente diagrama de paquetes ilustra la situación:

Fig. 1 - Modelo de sistema con parte dinamica y estatica.

Dicha división no significa que nosotros tengamos que dividir nuestros modelos en dos paquetes para acto seguido crear elementos y diagramas en cada uno de estos; muy por el contrario, la presentación de la parte dinamica y estatica se hace para cada modelo del sistema es decir, ya sea que estemos creando un modelo de requisitos, uno de análisis o presentando el modelo físico, en todos los casos tendremos diagramas que visualicen tanto el comportamiento dinamico como la estructura estatica del sistema.

Es mucho más habitual el presentar los sistemas con una colección de puntos de vista, y para cada uno de estos, mezclar diagramas dinamicos y estaticos.

"Quick Sequence Diagram Editor" is an open-source Java-based UML Sequence Design tool that uses a DSL (oooooo!) to generate UML diagrams that can be exported to a variety of formats. What I like best about this tool is not just that I can concentrate on describing the application in a way I am comfortable with (I am a programmer!) but that it also generates the diagram in a preview window as you type. Once you get used to the language it feels very natural to describe the flow without getting bogged down into the messy details of layout.

You can download the tool for free from SourceForge.net (http://sdedit.sf.net). As of the time of writing this the latest version was 3.0.5 and since it's a self-contained executable there's nothing to install. Just download and run! The only prerequisite is that you have a recent JVM installed on your workstation.

To show how simple the tool is and how terse the language is I'll replicate a simple sequence diagram from Agile Modeling by Scott Ambler. _{Visit Mr. Ambler's website, and read his regular contributions on Agile development in each(?) issue of Dr. Dobbs. (You do subscribe to Dr. Dobb's don't you?)}

I've taken one of the simplest examples that is a copy of a barely-legible hand-drawn sequence diagram and reproduced it in the Sequence Diagram Editor tool. This is taken from the UML 2 Sequence Diagrams article on Mr. Ambler's site.

That is much more legible now. And, the code is pretty straight forward, although if you've checked out the linked source article you'll see that the diagram isn't 'exact'. This is where any computer tool will always have difficulty, tradeoffs must be made and declarations must be explicit. I won't call them limitations but instead realities of how the tool implements the UML Sequence Diagram specification. Like anything else written by hand you can fudge the rules a little bit and get away with some things just because we can figure out what you meant pretty easily. But as programmers we all know that what looked fine when it was sketched on the whiteboard isn't exactly how it gets implemented.

Some of the changes that had to be made, is that Actor types in SDE can only send and receive one-way messages. Another is that one-way messages on Processes start new lifelines on the receiving process. Other than that I think it's pretty darn close for a 5 minute exercise. Now let's break down what we're looking at codewise.

Here we're declaring the Actors and Processes that will participate in the SD. The syntax is like NAME:TYPE[attributes]. When we get to the body it will become more apparent. So we have two Actors, these will be represented as stick-figures with their names displayed beneath them. Then we have a single Process that is a System. The [a] attribute means that the Process will be treated as anonymous, the name will not be displayed in the diagram because it is irrelevant.

Applicant:Actor
Registrar:Actor
S:System[a]

Now we're specifying the interactions between the Actors and Processes. The syntax is like CALLER:CALLEE.action. The callee is optional if the action is reflexive; the caller and callee are the same. Although there can be more done to specify responses and allot of other neat stuff this is enough to be productive.

As you can probably see, the code isn't directly mapping to methods, just describing interactions. So when you see Registrar:requests forms all we are saying is the Registrar Actor needs to perform some action and return immediately. But we aren't bogged down in the syntax of the whatever language we'll actually be developing in. Also, when we see S:Registrar.receipt, we are telling the S Process to invoke some action on the Registrar and return immediately.

Applicant:Registrar.application form
Registrar:requests forms
Registrar:S.create student
S:Displays UI 89-create statement
Registrar:S.input name, address & phone number
S:check to see if student exists
S:verify person is on eligible applicant list
S:add applicant to DB
S:calculate enrollment fees
S:display UI 15-fee summary
Registrar:Applicant.help student to enroll in semesters
Registrar:Applicant.request fees
Applicant:Registrar.payment
Registrar:S.payment
S:Registrar.receipt
Registrar:Applicant.receipt

The developer of SDE, Markus Strauch, was also kind enough to store the diagram descriptions as XML files only with a SDX suffix. So they are easy to version inside your source control repository or edit outside of the SDE editor. I even configured my system to open the SDE tool automatically when I double-click on an SDX file.

I hope that was enough to whet your interest in the Sequence Diagram Editor tool and to make Sequence Diagram generation a little less foreboding.

EmploymentContract can have either no Person object or 1 Person object
Person has exactly one EmploymentContract
EmploymentContract has >=0 Company objects
Company has exactly one EmploymentContract

Now, perhaps I'm reading too much into this, and perhaps this is a sign I hang out with too many lawyers (lol), but why would an EmploymentContract contain a Person if an EmploymentContract is a tangible object that a Person can have? An employment contract is an agreement between the employee and the company, and should contain information about the company (and shouldn't it be ONE company per contract?), how much they're going to get paid, benefits, whatever. And a person is able to work at one or more jobs, thus Person should be allowed to have >=0 EmploymentContract objects.

Employment contracts should have no knowledge of the people signing them, that should be in another class, perhaps called Employees, which exists for every Company and shows which Person has signed the EmploymentContract for that company. Thus every Company has an EmploymentContract for each type of employee they have (janitors and programmers may want different contracts, heh), so Company has >=1 EmploymentContract objects, and >=1 Person objects.

I'll post a diagram when I have the time (if there's even any interest lol), but yeah, all those two-way relationships where relationships shouldn't exist (IMO)...unnecessarily complicated.

• Build highly detailed UML 2.1 models.
• Manage project complexity.
• Reverse engineer legacy code and database schema.
• Produce great looking reports.
• Track change.
• Involve the whole team.

UML 2 defines 13 diagrams:

• Package diagrams.
• Class or Structural diagrams.
• Object diagrams.
• Composite Structure.
• Component diagrams.
• Deployment diagrams.
• Use Case Diagrams.
• Activity diagrams.
• State Machine diagrams.
• Communication diagrams.
• Sequence diagrams.
• Timing diagrams.
• Interaction Overview diagrams.

We discuss all diagrams below:

Package Diagrams
Package diagrams are used to reflect the organization of packages and their elements. When used to represent class elements, package diagrams provide a visualization of the namespaces. The most common use for package diagrams is to organize use case diagrams and class diagrams, although the use of package diagrams is not limited to these UML elements.

The following is an example of a package diagram.

Elements contained in a package share the same namespace. Therefore, the elements contained in a specific namespace must have unique names.

Packages can be built to represent either physical or logical relationships. When choosing to include classes in specific packages, it is useful to assign the classes with the same inheritance hierarchy to the same package. There is also a strong argument for including classes that are related via composition, and classes that collaborate with them, in the same package.

Packages are represented in UML 2.1 as folders and contain the elements that share a namespace; all elements within a package must be identifiable, and so have a unique name or type. The package must show the package name and can optionally show the elements within the package in extra compartments.

Package Merge
A «merge» connector between two packages defines an implicit generalization between elements in the source package, and elements with the same name in the target package. The source element definitions are expanded to include the element definitions contained in the target. The target element definitions are unaffected, as are the definitions of source package elements that don't match names with any element in the target package.

Package Import
The «import» connector indicates that the elements within the target package, which in this example is a single class, use unqualified names when being referred to from the source package. The source package's namespace gains access to the target classes; the target's namespace is not affected.

Nesting Connectors
The nesting connector between the target package and source packages shows that the source package is fully contained in the target package.

This tutorial is collected from following Source and use as it is: Sparxsystems.com

• Integer: números enteros tal como los conocemos. Incluyen tanto los positivos como los enteros así como el cero.
• Boolean: tipo de dato lógico, acepta los valores true y false; representado los valores de una expresión verdadero/falso.
• String: tipo de dato de texto o de cadena de caracteres. El nombre viene de la palabra inglesa cadena.
• UnlimitedNatural: Son enteros igual o mayores a cero, el valor de infinito se denota con un asterisco: *.

El siguiente diagrama de clases es tomado de la especificación de UML (conocida como meta-modelo de UML) y presenta los tipos de datos primitivos como parte del paquete respectivo: UML::AuxilliaryConstructs::PrimitiveTypes:

Fig. 1 - Diagrama del paquete PrimitiveTypes del Meta-modelo de UML

Estos tipos de datos primitivos son los únicos que legitimamente vamos a utilizar en la sección de atributos de nuestras clases; para todos los restantes elementos de datos se debe preferir por presentar una relación entre clases. Es decir, que las variables que colocamos en la sección de atributos de las clases van a ser casi sin excepción, de uno de los tipos primitivos: Integer, Boolean, String, UnlimitedNatural.

Hope I don't get in trouble for posting this or something, LOL.

Es interesante observar que llamamos actor a toda entidad externa que demanda funcionalidad del sistema, ya sea un ser humano o un sistema de software; por lo cual el término usuario puede ser un poco limitado.

Normalmente representamos a los actores de nuestro sistema por medio de la simple imagen de una figura humana de rayas. pero dada la flexibilidad del UML es posible representarlo también como una clase estereotipada o bien, con una imagen provista por nosotros según algún criterio artístico.

La siguiente imagen ilustra las tres formas que he mencionado:

Fig. 1 - Tres formas de representar un Actor en un diagrama de UML

La especificación UML lidía con el lenguaje visual pero como en otras ocasiones esta no es más que una fracción de lo que queremos decir sobre nuestros modelos, en este caso, es de interes capturar información adicional de nuestros actores, para lo cual podemos pensar en tener una tabla como la siguiente para cada uno de ellos:

Nombre: Actor
Representado por: Nombre y datos de contacto del stakeholder que puede responder preguntas sobre este actor
Facilidades de comunicación: Protocolos o estilos de comunicación que el actor entiende.
Relación con otros actores: Relaciones de herencia o dependencia entre actores

Tabla 1 - Definición de un Actor

La definición anterior la podemos llevar en el cuerpo de comentarios de nuestro modelador UML y exportarlo a un documento de texto cada vez que sea necesario.

Los actores nos sirven para capturar a los usuarios del sistema pero también, son la forma en la que podemos expresar el contexto del mismo. Es decir, que los actores toman el lugar de cualquier entidad de interes con la que nuestro sistema interactua.

Pese a lo anterior, ciertas cosas generalmente vistas como externas al sistema no son considerados buenos actores. Los sistemas de persistencia como las bases de datos o los archivos, si bien externos, no son actores. Entre otras cosas, debido a que estos no demandan funcionalidad del sistema (son pasivos respecto a él) además, es de interes que estos elementos estén bajo la definición del diseño de nuestro sistema, por lo que puede resultar de más provecho considerarlos parte del mismo.

• As a key figure in an international engineering team, you will be responsible for requirements gathering, systems analysis, design and build/implementation of 3 tier Java technology solutions which support worldwide premium products. The services for which this engineer is involved with support revenue generation from external customers in multiple countries and time zones. The chosen candidate will work for the Manager of Software Engineering for International and work closely with several teams who are based locally or in an offshore location. As well as hands on development, there is a significant proportion of the role required to provide internal consultation to business customers on technical solutions and provide input for scoping project costs. You will also be responsible for liaising with technical and non-technical staff from in the US, Japan and Europe, along with as necessary external developers from third party partners. This role involves a mix of hands on development and business facing consultation.

Job Responsibilities
• Liaise with technical and non technical customers worldwide to produce and deliver business and technical requirements specifications.
• Undertake system / architectural design and review employing best industry practice.
• Take responsibility for producing detailed system designs and implementation plans, working with the rest of the engineering team and ensure all team members produce consistent output in line with best practice.
• Develop and ensure solutions are tested in accordance with the QA team
• Ensure there is consistent production of design, maintenance and operational documentation.
• Maintain and enhance the development environment and advance the technical systems architectures and technologies.
• Support global development teams and external clients in the use of the standard technology platform.

 Qualifications For Position
• Software development of computer sciences degree.

Experience For Position
• 5+ years working in a recognized professional software / internet development company.
• 5+ years development and delivery of online products or services.
• 5+ years architectural design and implementation of J2SE/EE solutions.
• 3 years exposure to end-user facing web development frameworks.
• 3 years exposure and practice in all areas of the software development life cycle. (requirements, design, implementation, testing, maintenance)
• Experience working with non-technical customers and having the unique ability to convey technical issues in a business context.

Technology Experience
• Operating systems: Windows 2000/XP, UNIX/Linux, Dos
• Programming: JSP, MVC Frameworks, Spring, JMS, JDBC, Servlets, EJB, XML, HTML, SQL
• Design Methodologies and tools: UML, OOA/D, Rational
• Application Environment: Weblogic  6+ , Tomcat, JBoss, MS SQL Server 2000+
• Java Development Environment: Eclipse
• Source code control systems. (e.g. Microsoft VSS, CVS, SVN, Perforce)

Specific Skills Required
• Highly competency in J2EE architecture and development.
• High competency in relational database development
• Excellent communication and interpersonal skills.
• Excellent written and spoken English

Advantageous Experience
• Experience of commerce related projects.
• Experience of leading teams of developers.
• International experience.

laszlo_spiller@kellyservices.hu