Software modelling

Imagine that you’ve defined your requirements. You know who your users are, what they need (which may be different from what they want). You’ve identified a problem and the components of a solution. What comes next?

You need to start modelling your application, determining how to structure your application to meet these requirements.

There are three overarching principles that guide software modeling activities:

1. Model the essentials: Good models do not represent every minor feature for all scenarios. Modeling involves the most salient aspects needed to address the specific issues or questions. Trivial details are abstracted away to keep the model understandable and wieldy. This focuses on key characteristics for informed decision-making.

2. Provide perspective: Modeling constructs different views using defined rules to express each within the chosen modeling language and tools. This multifaceted, perspective-driven approach brings dimensionality. For example, models may provide structural, behavioral, temporal or organizational views. Organizing into separate views focuses on modeling for each view on specific concerns.

3. Enable effective communication: Diligent, uniform modeling facilitates straightforwardly conveying software information to stakeholders. Careful use of domain terminology and modeling language semantics enables articulation in a familiar vocabulary. Strict syntactic and semantic adherence also improves expression. Explicit notation contributes to communicative models, while modeling pragmatics helps share unambiguous meaning.

What does each model typically consist of?

A typical software model consists of an aggregation of multiple submodels. Each submodel provides a partial, simplified description and representation of some aspect or perspective of the software under consideration.

What is behavioral modeling?

Behavioral modeling is a model type that focuses on identifying and defining the dynamic behavioral aspects of software components. The goal is to represent how software functions, features, and system elements behave when in operation.

Behavioral models generally take one of three basic forms:

• State machine representations – These models depict software behavior in terms of defined states that the software or components can be in, along with events that can trigger transitions between those states. State machine modeling is valuable for elucidating complex workflows, protocols, lifecycles, and user interaction flows.
• Control flow models – These behavioral models illustrate software behavior through sequences of events, triggers, and messages that cause software processes to be dynamically activated or deactivated over time. Control flows are useful for expressing orchestration and coordination logic.
• Data flow models – This form represents software behavior in terms of how data moves through various processes, transformations, and mappings in route to its ultimate destination in data stores or data sinks. Data flow modeling helps clarify throughput and signal processing behavior.

Domain-Driven Design

Domain-Driven Design (DDD) is all about building a model that reflects the real-world domain (aka “problem area” in which your working). As a software developer, your goal is to build an understanding of the problem domain, and then building classes and functionality that reflect the real-world domain. You may even go so far as to define a Domain Specific Language to reflect the problem domain using domain-specific terminology.

For example, in a DDD model of a banking system:

• You might have classes like Customer, Account, Transaction.
• Your class methods would be actions in the business domain, like withdraw, deposit, authorize.

DDD excels in building up a system that needs to accurately reflect a real-world system or process, along with all of it’s constraints and rules. e.g., a medical imaging system that stores and manipulates medical images is very likely going to be build to accommodate an existing process within a hospital. Getting the domain correct is critical for this type of software!

Goals of DDD

Domain-driven design is predicated on the following goals:

• Placing the project’s primary focus on the core domain and domain logic layer;
• Basing complex designs on a model of the domain;
• Initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.

When to use it?

When should you use this?

• Your problem domain is extremely complex and you need to ensure that you are “following the rules” of the domain.
• You need to engage domain experts, and require their input in your design to encode these rules. DDD provides you with a common set of terminology that you can use e.g., you can discuss the behaviour of your design in terms of the problem domain.
• Your business domain is growing and evolving. DDD is suitable since you can grow the system as your understanding of the domain grows.
• You need to split development across a large number of teams or developers. With DDD it may be easier to isolate parts of the system to be developed independently.

When should you not use this?

• It doesn’t suit more abstract problems.
• Your problem isn’t modelling a real-world system.

Last Word

https://xkcd.com/1739