Archives: Templates

Tree signifies that an element is a component of another element of the same type. This highlights hierarchical relationships, where a dominant element encompasses others as its constituent parts.

Examples:

• Organisations manifesting as a tree of roles, teams, and departments.
• Capabilities branching into various sub-capabilities.
• Product portfolios dividing into categories, components, and individual products.
• Brand portfolios distinguishing between corporate, product, and special edition brands.
• Goals arranged hierarchically from strategic to tactical and operational outcomes.

Applications: The ‘Tree’ structure aids in:

• Breaking down an element into its nuanced sub-elements.
• Denoting that a smaller entity forms part of a larger one.

In a nutshell, the ‘Tree’ concept in EDGY represents structured hierarchy and part-whole relationships within an enterprise.

The Tree is a part of the EDGY language created by the Intersection Group.

Flow signifies how one element influences another by transmitting objects. It’s the backbone of an enterprise, highlighting how interconnected parts collectively produce results unattainable individually.

Examples:

• Teams relying on information from others.
• Monetary transactions between businesses.
• Data shifts between software systems.
• Movement in supply chains.
• The energy in team collaborations.
• Public enterprise goals tied to budgets.

Applications: ‘Flow’ aids in:

• Facilitating communication.
• Optimizing processes.
• Mapping task sequences.
• Identifying inter-organizational flows.

In essence, ‘Flow’ is the dynamic force driving collaborative efficiency in an enterprise.

The Flow is a part of the EDGY language created by the Intersection Group.

Link is a fundamental concept denoting a meaningful structural association between two elements. Far from being a mere connection, a link elucidates the relationship between these elements, illuminating its relevance within the broader scope of the enterprise.

Types and Facets of Core Links: EDGY modeling boasts a rich lexicon with twenty-four pre-defined types of links. This variety allows for a nuanced expression of relationships between design elements, ensuring both clarity and specificity. These links have been categorized into several facets:

1. Identity:
   • Story contextualizes purpose.
   • Content expresses purpose.
   • Content conveys story.
2. Experience:
   • Task is part of journey.
   • Task utilizes channel.
   • Journey traverses channel.
3. Architecture:
   • Capability requires asset.
   • Process realizes capability.
   • Process requires asset.

… and so on, for each facet.

By utilizing these core links, co-designers from diverse disciplines can engage in a richer dialogue, enabling them to integrate their specialized designs more effectively across their respective fields.

The Link is a part of the EDGY language created by the Intersection Group.

PackageMerge is a template in a Class Diagram that represents a relationship between two packages, indicating that one package (the receiving package) is merging with another package (the merged package). PackageMerge is used to combine or merge the contents of the two packages, integrating their elements in a way that creates a more coherent or simplified model. The receiving package effectively absorbs the contents of the merged package, including its classes, interfaces, datatypes, and other elements.

The PackageMerge relationship helps to manage complexity and maintainability by allowing you to refactor or reorganize the model as it evolves. By merging related packages, you can simplify the structure and reduce potential redundancies or inconsistencies.

Example: In a Class Diagram for a system that manages a hotel booking platform, you might initially have two separate packages: “GuestManagement” and “ReservationManagement”. The “GuestManagement” package contains classes like “Guest” and “GuestPreferences”, while the “ReservationManagement” package includes classes like “Reservation”, “Room”, and “Booking”. As the system evolves, you may decide to consolidate these related packages into a single, cohesive package called “BookingManagement”. You can use a PackageMerge relationship to merge the contents of the “GuestManagement” and “ReservationManagement” packages into the “BookingManagement” package. This simplifies the model and makes it easier to understand and maintain.

PackageImport is a template in a Class Diagram that represents a relationship between two packages or namespaces, indicating that one package is importing or including elements from another package. PackageImport enables modularity and reusability by allowing a package to use the elements (such as classes, interfaces, or datatypes) defined in another package without the need to duplicate their definitions.

By using PackageImport, you can create modular and organized designs, where related elements are grouped together into separate packages. These packages can then be reused and shared across different parts of the system or even among different projects.

Example: In a Class Diagram for a system that manages an online store, you might have two packages: “ProductManagement” and “OrderManagement”. The “ProductManagement” package contains classes like “Product”, “Category”, and “Inventory”, while the “OrderManagement” package has classes like “Order”, “OrderItem”, and “ShippingInfo”. To create a relationship between an “OrderItem” and a “Product” in the system, you can use a PackageImport relationship to import the “ProductManagement” package into the “OrderManagement” package. This way, the “OrderItem” class can reference the “Product” class without duplicating its definition, and the two packages can evolve independently while maintaining their connections.

Enumeration is a template in a Class Diagram that represents a distinct set of named values, also known as enumeration literals. Enumerations are used when an attribute or parameter has a limited number of possible values, and each value can be uniquely identified by a name. Enumerations help to make the model more expressive and easier to understand, as they allow you to use meaningful names instead of arbitrary numeric or string values.

Example: In a Class Diagram for a system that manages event bookings, you might define an enumeration called “EventType” to represent the different types of events that can be booked. The EventType enumeration could have the following literals: “Conference”, “Workshop”, “Seminar”, and “Webinar”. Then, you can use this enumeration as the type for the “eventType” attribute in the “Event” class, indicating that only the values defined in the EventType enumeration are valid for this attribute.