UML Operator Blog

On the UML Operator Channel our focus is on Model-Driven Anything. In Sparx Enterprise Architect (EA), we are able to model-drive all aspects of delivery. From Ideation to Code Deployment and Test, Computer Aided Design (CAD), whether simple Unified Modeling Language (UML), Computer Aided Software Engineering (CASE), Business Process Engineering (BPM, BPMN, or BPEL), any delivery is possible. Model-Driven Design Model-Driven Design (MDD) is an approach to software development that emphasizes the use of models to describe various aspects of a system's structure, behavior, and functionality, and to drive the development process. In MDD, models serve as the primary artifacts for communication and analysis among stakeholders, and they are used to generate executable code or other artifacts. Here are key concepts and principles of Model-Driven Design: Abstraction : MDD promotes the use of abstract models to represent different perspectives of a system, hiding implementation details and...

In the previous episode, " From UML Class to Code ," I attempted to expose Platform Independent Modeling (PIM) leading in  Design  so that we can transform to a Domain Specific Language(s) (DSL). I also stated that we do not teach "coding" on this channel, but I do not want to confuse or mislead modelers who are focused on  Design . In our next episode, Model-Driven Design (PIM to DSL Part 1) , I will further explain so that  Design  can be accomplished  in a manner that is not disruptive to the project or your developers. With that said, let's preface  once  again that our focus when doing PIM is "Design ".   This  should be referred to as "High-Level Design" as more "Detailed Design" would be using  real  software language (or Code). So  with  that now said, let's break this episode into two parts: High Level Design and Detailed Design as we move from Model-Driven Design to Model-Driven Code (Development). High-Leve...

Design is the process of creating a plan or blueprint for the construction or realization of something, whether it's a physical object, system, structure, or experience. It involves generating ideas, making decisions, and defining specifications to achieve a desired outcome or solve a particular problem. Too many times, delivery stalls because teams do not start Design early enough. The key is to work in iteration: Analyze, Specify, and Validate in iterative cycles. You do not need to be an expert to start design. Use Design Approaches that work best for you and your team. Software design is the process of conceptualizing and planning the structure, behavior, and functionality of software systems before they are built. It involves transforming requirements into a blueprint that developers can follow to create the software. Software design encompasses various activities and artifacts aimed at ensuring that the resulting software meets the desired specifications, is maintainable, sca...

In this episode, we will focus on " Inspector ". In Sparx Systems Enterprise Architect (EA), the Inspector is a panel that provides detailed information and properties of selected elements within a model. It allows users to view and modify various attributes, relationships, and other details associated with elements such as classes, objects, use cases, actors, etc. Over the past couple of years, I have been in projects where project teams are using a Wiki to drive their projects. First off, I am not against this by any means. After all, wikis started as Knowledge-Management platforms and what is more important to project delivery than access to knowledge, right? However, and OMG!, if you cannot effectively manage knowledge, how useful is your Wiki? Thus to my point about seeing the most atrocious uses of Wiki and then wondering why the company has so much trouble with delivery and/or managing their architecture. What I see is more like "fire and forget"...literally!...

There is a big difference between Drawing Tools and Modeling Tools such as Sparx Enterprise Architect (EA).  Any modeling tool that models data around diagrams rather than tools that  simply  draw shapes and lines . Sure, some drawing tools have some "properties" relevant to shapes applied to a drawing area, such as date/time and metadata  relevant  to the element  being applied . However, this is  nowhere near enough  to support effective system/software architecture or engineering. If pictures speak a thousand words, it best to see the "thousand words" the picture is speaking! I am in too many projects where architects, engineers, and modelers present a picture, either in a Wiki, PowerPoint, PDF, or other platform , and then cannot   speak  effectively (or remember) what the  picture  they are  speaking  to represents. And if there is a problem or  question,  they cannot effectively address or fix. The pro...

For decades, I have worked with many Architects whom are not "Developers". Many say they started as a Developer, yet this doesn't seem to be reflected in their Solution or Application Architecture presented in projects. When I ask why, the answers vary from, "I am out of date with current technologies", to " I'll leave that to the Application Architect or Developers". My response is, "That is too late!". Often at the start of the effort (e.g., Project), necessary resources are not available. This could be that resources are tide up in other delivery, to the budget doesn't allow for IT. My response to this reasoning is, "You can pay now, or pay considerably more later!". In the beginning of any effort, and at a minimum, there should be a primary facilitator (e.g., Project Manager), the primary client stakeholder (e.g., Sponsor funding the effort), a primary product or company knowledge source (where knowledge is methods, proc...

I have always said the #1 most important role, in systems and software delivery, is the Code Slinger (Developer), where #2 is the Project Manager. However, in the beginning of any project or delivery exercise, we are trying to develop and validate the "Requirements" for the effort. In other words, understand the problem(s) to solve. I find that in almost every project, when I arrive to assist in better delivery results, the team is missing important roles at the start of the effort. One of those roles is a "Tester" or "Quality Assurance" role. This is usually the person or role that knows how the business or shop does things, like methods, procedures, rules, and processes. The Testing role probably should have been the first "role" that the Project Manager asked for, even before me (the Solution/Enterprise Architect 😎). The "Testing" role is usually a stakeholder responsible for "Quality" in the Company, Organization, or Deve...