Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - jaimeglz

Pages: [1]
1
General Board / Import from Informix
« on: March 15, 2005, 01:13:27 pm »
Hi all,

Has anybody successfully imported tables from Informix into EA?

Thanks in advance,

Jaime

2
General Board / Request on state elements in sequence diagrams
« on: September 17, 2002, 08:14:30 am »
Hi, everybody!

Here's a request for Sparx on sequence diagrams, as well as a work-around for the problem I want to address.

State charts are a powerful tool for analyzing objects with non-trivial life-cycles, but they are oftentimes neglected for a variety of reasons: time pressure, learning curve, and so forth. A good alternative to state charts consists of including the states of objects in sequence diagrams. Rumbaugh and his amigos give an example of this in page 426 of The UML Reference Manual (Addison-Wesley, 1999): interactions with a :TICKET object produce transitions through "unreleased", "available", "locked" and "sold" states .

The way I make use if this technique in EA is as follows: I include a state in a sequence diagram (drag the "State" shape from the State tool bar into the diagram), send a message to the state (in the usual way), and specify "New" in the message's lifecycle Box (so as to force the state to the message's vertical position). I then superpose the state above the corresponding object. For example, I place a "logged_in" state over an instance of "user" class.

This is only a workaround, and any ideas or successful experiences from other EA users will be quite welcome.

To permanently solve the usage of states in sequence diagrams, I would like to see two improvements in EA: first, the state should be displayed with a state shape (as it is correctly displayed in EA state charts diagrams), and I should be able to place it vertically wherever I need it; second, the state should "snap" over the object (since it is the state of a class' instance) and should not have a lifeline of it own.

From my perspective, what I am requesting is not an urgent improvement, since developers are being able to understand  diagrams like the one just described. But I hope that the use of states in sequence diagrams can help the EA community to improve our use of the tool, as well as our productivity. The correct displaying of the state element's shape, and the behavior of the object and its state as a unit will help us in this regard.

A couple of notes of caution, though, for those of you who are using sequence diagrams and would like to include states. First, you should not worry about states until you have a stable use case model; otherwise, you will be doing and undoing a lot of work. Also, you should take into account that it is valid to use sequence diagrams to represent the behavior of either classes or objects. State transitions, however, apply almost always to objects (instances of classes) and not to their classes. This is very logical: when my cat Timoteo falls into the "lazy" state, it does not mean that the whole class of felines falls also into that state as well. So, if you draw a state over a class, some unforgiving zealot might use the opportunity to step on your toes.

Jaime Gonzalez

PS: The only urgent reason for this improvement would be to get it working before Farfetch's boss finds out that Visio does snap state shapes over object's lifelines in sequence diagrams!

3
General Board / Eriksson-Penker extensions stereotypes
« on: August 28, 2002, 12:16:46 pm »
For a couple of months I've been successfully using EA's Eriksson-Penker extensions (downloaded from EP_Extensions in "UML Profiles" at EA's web site). Great stuff! Once more, congratulations, Sparx.

EP extensions might sound esoteric, but they are a big practical help in modeling processes (see Hans-Erik Eriksson and Magnus Penker: Business Modeling with UML, published by OMG Press-John Wiley & Sons).

I know this is a low priority suggestion, but could it be possible to have the EP stereotypes (goal, information, supply...) automatically incorporated to their respective artifacts (Reference -> Stereotypes) upon loading these extensions? Currrently, I have to enter them manually.

Thanks.

Jaime Gonzalez

4
Uml Process / A first contribution on the PUP/EUP
« on: December 07, 2002, 09:28:50 pm »
Here's a first contribution on Phil's Unified Process, the PUP. (Please note that it has also been proposed to be named the EUP, but we can decide on the name later).

This will be an open and free development process for software and general business engineering, with no other obligation for those who use it other than making an explicit reference to the source (and, if applicable, to the authors).

Insofar as the source is concerned, I suggest Sparx should set-up a special section of this «General» forum for this discussion, where we can have threads for diverse aspects and/or issues in methodology and project management.

I hope that volunteers will later compile, translate and copy-edit the contributions and agreements in a general documentation project (probably like The Linux Documentation Project at http://www.tldp.org/ ).

If accepted by other forum participants and by Sparx, we will embark on an ambitious project that requires an honest and sustained collaborative effort. So, in the next paragraphs, I'm suggesting a way to break-up this huge task into a reasonable and practical way of producing useful documentation.

But before we get into the matter, let me propose some rules:

1. All ideas are welcome, and references and short quotations from diverse sources are in order. But forum members should not include in their contributions copyrighted or proprietary material (except, of course, with written permission to do so for a free and open development process).

2. Parts --even substantial parts-- of existing public-domain or free process descriptions and documentation are welcome to be included, because they will make our task easier; but please make at least a summary motivation for it in the forum, and not just sweeping statements.

3. Debate is the best way to advance any issue where disagreement or contradiction arise; but net-etiquette and respect among participants are imperative if we are to gain clarity. Participants who incur in flaming others will be called to order and, if agreed by at least five other participants who have been in the forum for three or more months, postings that break net-etiquette can be branded as «offensive to the purposes of this forum».


First issue to deal with: the software life-cycle

The first thing we have to deal with is a generalized process for the lifecycle of a software product; in other words, with a software analysis, design, building, transition, maintenance and replacement/disposal process.

According to the terminology used in A Guide to the Project Management Body of Knowledge(or PMBOK Guide, by The Project Management Institute, 2000 Edition), what I am proposing to deal with first is called the «product oriented process», which «specifies and creates the project's product». This process is quite specific for each discipline (in our case, software development), and is one the two major categories of project processes. The other major category is the «project management process», which is applicable to most disciplines, and «describes, organizes and completes the work of the project». The latter includes (and this is my terminology) logistics, risk management, inter-personnel relationships, accounting/budget, quality and related issues, and I propose we postpone dealing with it until we have achieved at least a workable «light-weight» product oriented (analysis, design, building and transition) process.

The concrete expression of a product oriented process is that part of a Work Breakdown Structure (WBS) that contains a hierarchy of deliverable-oriented tasks pertaining to the software product's life-cycle.

If there is any enthusiasm out there for this effort, please respond to this thread, and I will begin my contributions to the PUP's WBS.

Jaime Gonzalez

5
Uml Process / Project scope document: Why I have found it useful
« on: December 15, 2002, 10:16:48 pm »
I want to share a technique that I learned from datawarehousing experiences, and have been using successfully for the last two years: the project scope document.

In a nutshell, the idea is to produce, at the very early stages of the project and within a relatively short period of time, a document that will be agreed upon by the sponsor and all other key project participants, and that clearly delineates the scope of the project.

The main value of this document is to mitigate scope-creep.

The project scope document has essentially the same structure as the technical-description section of a project proposal; and, indeed, the technical section of a proposal can be considered as a scoping document. But I would like to stress that "technical section of a proposal" is a limited concept in comparison to the sort of document I'm talking about here.


Components of the project scope document

The scope document I will describe here is based on real proposals and/or scoping documents intended for two to six-month projects; so keep in mind that I'm using "light-weight" examples, which are ideal to explain the main ideas, but that do not cover the needs of either very short or very large projects.  Almost needless to say, not all sections of the example described here are necessary for each and every project.

Executive summary
For "light-weight" projects, I suggest to keep it less than one-page long.

Introduction
"On October 9, 2002, XCo, SA invited TYSG, SA to prepare a proposal for the development of a Sales Analysis Decision-Support System. The document that follows has been prepared in response to the aforementioned invitation. In this proposal, we outline a roadmap intended to fulfill XCo's request."

Scope
"1. The scope of this project is constrained to implementing a Sales Analysis Data Mart (referred to henceforward as «the data mart»).

"2...."

Links to the overall organization strategy
"The system is needed critically for driving revenue and forecasting plan management". It is usually a very short section, but it is one of the most challenging parts of the document.

Project Goals
"Based on the scope outlined, the goals of this project can be stated as follows:

"1. Ensure that existing source data will be usable in a data mart. This will be achieved by conducting a data quality survey of XCo sales information, as it exists in its source systems.

"2. Implement a technical solution for the extraction, transformation and loading (ETL) of..."

Objectives
"1. Project personnel will avoid unnecessary distractions to users and executives by initially examining all relevant, existing material...

Assumptions
"1. Senior management will remain committed to the goals and objectives for the duration of this effort..."

Critical success factors
"1. Strong, visible management support for the project...

Constraints
"1. The project will be developed within estimated cost and time..."

Security Issues and Concerns
"TYSG strongly recommends that worldwide sales data should be encrypted before it is transmission from one subsidiary to another..."

Acceptance Criteria
"The system must prove its capacity to accurately store and retrieve one month of the information needed to answer the business question..."

Processes
If time allows it, present a business process overview. You can use this model to further explain and illustrate the project's scope. For general guidelines on this type of diagrams see Sparx Systems' "The Business Process Model". For an in-depth discussion, see Chapter 3 in Erikssonn-Penker: "Business Modeling with UML".

Business question
This section applies only to datawarehousing projects: "What are the organization's sales, in terms of quantity (in kilograms) and extended price (in local currency, Euros and US Dollars), grouped or broken down according to the following criteria: Customer, Product..."

Domain model
If time allows it, include a small diagram of real-world objects (customer, salesperson, product...) in your target area, and their relationships. The simplest form of a domain model is a non-attributed class diagram.

"Real-world" objects can be discovered by carrying out a quick use-case/scenario modeling session (and I will present a future contribution on this).

Technical architecture (and/or technical architecture alternatives)
Existing and/or alternative technological architecture at the subject area is depicted in a deployment diagram.

Project Roadmap
"The detailed project roadmap can be found in the attached Gantt charts and in the ROUTE01.XLS file provided in ...

Project Roles and Development Team
Actors and/or «workers» (user, manager, subject-matter expert...) are placed in the project org-chart (which can also be used as a project directory).

If there are open issues, include a section with short descriptions of these.

For elegance, and if time allows it, create a section on Glossary and Acronyms

Finally, if needed, create a section on Bibliography and References: "The classical book on data marts is Ralph Kimball's The Datawarehouse Toolkit (Wiley & Sons, New York)."

A good project scope document is never produced during a first iteration; so do plan for a total re-do of your first draft.

If you have not written formal statements of work, or technical proposals, your first try at a project scope document will take about a week (including interviews and/or Joint Application Development sessions) for a "light-weight" project. This time will be substantially reduced in subsequent scoping efforts, once you can use a good previous scope document as a template; but keep in mind that you still have to do the interviews and/or JAD sessions.  

Most components of the scope document map very nicely to tasks and deliverables in the next project stages; for instance, the domain model derives directly into one or several class diagrams.

Also, the scope document is very useful when you find yourself in a situation in which the project is directly assigned, without contract or formal documentation. If this is the case, the first task in the project should be to draft the project scope and have it approved by the project's sponsors.

You're in a real hurry and don't want to loose time drafting a formal document? Then just conduct a session with the project sponsor and get agreement on the main points mentioned above; but I would suggest for someone to tactfully take good notes of the session's agreements.

Jaime Gonzalez

6
Uml Process / Mission/Vision statement
« on: December 11, 2002, 09:39:40 am »
Here's a proposal for a preliminary general mision/vision of this forum, as well as on its relationship to the UML. I hope I have reflected the variety of views that have been expressed on this topic.

Mission:
The open UML Unified Process forum intends first of all to provide a workspace for discussion and orientation on the software product lifecycle; that is to say, on issues pertaining to the general process of analysis, design, construction, transition and replacement/disposal of software products.

(Forum participants with specific questions on the use of  existing software tools are advised to post in the appropriate forums.)

Vision:
In the long run, this forum is intended as a means to orient in the usage of existing open software development processes, and to the development of new ideas and contributions in the field of software product processes.

The forum is considered "open", because it will try to draw from the widest range of both formal and informal experiences in software development. Whenever no legal limitations or liabilities are found, the open Unified Process will highlight and help propagate other software or business engineering processes' best-practices and ideas.

The forum is intended to be independent of any product or tool (though we must gratefully acknowledge Sparx Systems' hosting this discussion in its forum).

The open Unified Process and UML
The Unified Modeling Language (UML) has been a great step forward, because it provides a widely accepted standard for diagramming and specifying a software product; but the UML does not provide guidelines on where to begin, and what steps to follow in a software development process. This forum intends to contribute in bridging this gap.

Jaime Gonzalez

7
Uml Process / General rules for participating in this forum
« on: December 11, 2002, 08:06:48 am »
Here's a proposal for general rules for all participants in this forum (drawn form my Dec. 7th proposal in the General Discussion forum).

1. All ideas are welcome, and references and short quotations from diverse sources are in order. But forum members should not include in their contributions copyrighted or proprietary material (except, of course, with written permission to do so for a free and open development process).

2. Parts --even substantial parts-- of existing public-domain or free process descriptions and documentation are welcome to be included, because they will make our task easier; but please make at least a summary motivation for it in the forum, and not just sweeping statements.

3. Debate is the best way to advance any issue where disagreement or contradiction arise; but net-etiquette and respect among participants are imperative if we are to gain clarity. Participants who incur in flaming others will be called to order and, if agreed by at least five other participants who have been in the forum for three or more months, postings that break net-etiquette can be branded as «offensive to the purposes of this forum».

Needless to say, other ideas and contributions on this topic are welcome.

Jaime Gonzalez

Pages: [1]