Software Engineering - Design
Domain Data
Describes entities (things and concepts) important in the context.
Explains terms used in client's descriptions.
Usually described by simple class diagrams (attributes and operations may not be captured).
Cardinalities and relationships are important.
A glossary is often sufficient or supplementary.
Goal: Understand basic entities of the real world and their relationships necessary to understand the task.
Historically: ER diagrams (ERD) were used for data description in database development (Peter Chen, 1976).
Describes, at a high level of abstraction, the data relevant for the system to be developed.
Identify Domain Data
Which nouns have been used in the descriptions so far?
Which of the nouns are synonymous?
Eliminate them and decide on ONE term.
Record your decision in the dictionary as a synonym that should not be used.
Specify vague terms.
Use linguistic analysis for the identification of data.
Use Case Example: Withdraw Money From an ATM
Name: Withdraw money from an ATM.
Actors: bank customer, banking system
Precondition: Bank customer has money in the account, ATM is operational.
Triggering event: Person wants to withdraw money.
Main scenario:
Bank customer inserts card into the ATM
Banking system asks the bank customer for PIN
Bank customer enters PIN
Bank system validates the card and authenticates the bank customer
Bank system asks for amount to be withdrawn.
Bank customer selects a predefined amount.
Alternative: Bank customer enters amount.
Banking system issues card and then the money
Identify nouns in use cases.
Identifying Domain Data Example
Customer explains what the system should do: "Peter Winter should be able to use the online conference system alongside other people at the TH Aschaffenburg. The system should work via SSO …"
Use linguistic analysis for the identification of data
Nouns?
Synonyms?
Too general?
Too specific?
What questions do you need to clarify in more detail?
Relationships Between Data
Associations between classes model possible object relationships between class instances.
Example:
Meeting
Participants
take part
1
1..*
Reading direction (not!!! navigation direction)
Association name
Cardinality: Number of objects that can be related to exactly one object on the opposite side.
Associations → Navigability
UML standard: Association direction not yet defined.
In practice often equivalent to:
Bidirectional navigability
Unidirectional navigation from "left to right", not defined in the other direction.
Navigable from left to right, but reverse navigation is not possible.
(Same as 2)
Associations → Cardinalities, Roles
Owner 1 Car 0..*
A car has exactly one owner, an owner can have none or several cars
The company Employee 0..* 1..*
At least one employee works in a company; an employee can work in several companies.
Person Child 0..* Parents 2
Role in a relationship
Reflexive Association
Cardinality:
Exactly 1: 1
>= 0: * or 0..*
0 or 1: 0…1 or 0,1
Fixed Number (e.g., 3): 3
Range (e.g., >= 3): 3..*
Range (e.g., 3 to 6): 3..6
Enumeration 3,6,7,8,9 or 3, 6..9
N-ary Association
Menu Appetizer Dessert Main course
0…* 0..* 0…*
N-ary association
Menu Appetizer Dessert Main course
1..3 1 1
0…* 0..* 0..*
Relationships Between Data: Aggregation
Special form of association
"is-part-of" relationship: There is a superordinate whole that contains a subordinate whole.
UML distinguishes between two types of aggregations:
Weak aggregation (shared aggregation)
Strong aggregation - composition (composite aggregation)
Relationships Between Data: Aggregation Properties
Transitivity: If C is part of B and B is part of A, then C is also part of A. (If the cooling system is part of the engine and the engine is part of the car, then the cooling system is also part of the car.)
Anti-symmetry: If B is part of A then A cannot be part of B. (If the engine is part of the car, then the car is not part of the engine)
Weak Aggregation
Parts independent of the whole.
Cardinality can be > 1.
The "parts" also exist without the whole.
Or: If the whole is deleted, the parts can still exist.
Example: Document Text module Graphic
Strong Aggregation → Composition
A part can only be part of a whole at any given time.
Cardinality MAX 1.
If the whole is deleted, the parts are also deleted.
Cardinality 1 can also be found in the literature ( → existence dependency).
The part cannot exist without the whole.
Example: Document Text module Graphic Comment
Strong vs. Weak Aggregation: Key Questions
Visibility: Is the part only visible to the whole?
Yes: strong aggregation (composition)
No: weak aggregation
Lifetime: Does the part exist when the whole thing is deleted?
No: strong aggregation (composition). The whole creates and deletes the parts.
Yes: weak aggregation
Copy: What happens when the whole thing is copied?
Strong aggregation (composition). The whole and the parts are copied
Yes: Only references to the parts are copied.
Aggregation Example
A car has exactly four tires. 4 tires are mounted to zero or one car at any one time.
Correct → A car has exactly four tires. 4 tires are mounted on exactly one car at a time.
→ Cardinality incorrect, tires do not have to be mounted
A car has exactly four tires. 4 tires are mounted to any number of cars at any one time.
→ Wrong
A car has exactly one/two tire types. A tire type can be mounted to any car. The same tire types must be mounted on the axles.
Relationships Between Data - What is What?
Inheritance
Parent class
Subclass
Interface
Class
"is-a" relationship
Implemented behavior
Implementation
Generalization
Association
has a relationship
Class A
Class B
Aggregation (weak)
Whole
Part
"is part of" Relationship
Aggregation (strong)
Whole
Part
"consists of" Relationship
Errors in Class Diagram Example
The name is not a class variable
The name of the class should be changed.
The class is defined twice.
Wrong direction for generalization.
Incorrect cardinality for the composition.
Summary: Context and Domain Level
Understand user context is important when designing the user experience.
Product vision and goals, user stories, tasks and use cases, domain data, roles and persona characterize this context.
This ensures that the right tasks are supported.
Care is taken not to introduce technical considerations unnecessarily early on.
Domain data describes entities in the real world and their relationships with each other.
A simplified UML class diagram can be used for the graphical representation.
The Design Refinement Process
The process goes from Context level, Domain level, Interaction level, System level until "Coding"
Determine and model design Implement design
Gradual refinement of the system, different views here too
Division of the system into manageable units, course granular design (architecture in the narrower sense), fine granular design
Goal of the design
Design, Architecture Definitions
Design: (1) The process of defining the architecture, components, interfaces, and other characteristics of a system or component. (2) The result of the process in (1). IEEE Std 610.12 (1990)
Architecture: The fundamental organization of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution. IEEE Std 1471 (2000)
Architecture describes the result, design both the activity and the result.
A software architecture therefore describes the basic organization of a software system with all its components and their relationships with each other and their environment. It also describes the underlying principles that guide design and development.
Design, Architecture Components
A component is a part of a system.
The architecture determines which components a system should consist of.
A component is atomic or more refined; it offers its environment a set of services that can be used via a well-defined interface.
Design, Architecture Component Definition
“A software component is a unit of composition with contractually specified interfaces and explicit context dependencies. It can be deployed independently and is subject to composition by third parties.” [WCOP 96]
WARNING: „Components are for composition, much beyond that is unknown. “ [after Szyperski]
Design Directions
Iterative process that encompasses all directions
Top-down
Bottom-up
Outside-in
Inside-out
Reverse engineering, bottom-up development
Step by step Refinement
Deriving a Good Software Architecture
In general: A software architecture is good if the functional and non-functional requirements can be fulfilled.
There is no design method that guarantees a good software architecture, but there are a number of proven design principles and design patterns that help to answer the following questions, among others:
What criteria should be used to divide the system into components?
Which aspects should be summarized in components?
Which services should components offer to the outside world at their interface, which aspects must be protected?
How should the components interact with each other?
How should components be structured and refined?
Architecture and Quality
Architecture decisions have an enormous influence on the quality characteristics of a software system
Quality Features and Prioritization
Quality features influence each other, there is no "perfect architecture" that fulfills ALL quality features equally.
Prioritization of the quality design is important!
Security vs. Usability Example
Use of multiple authentication levels Increases security
Affects usability
Users use weak passwords that they can remember, do not log out, use the same passwords, etc.
Reliability vs. Maintainability Example
Availability of a system: % of the time the system is available.
A system that should be available 99.9% of the time
system is available 86313 out of 86400 seconds a day.
Highly redundant systems. E.g. online banking
With all the disadvantages of duplicates (maintenance, costs, …)
Architecture and Complexity
Architecture has an influence on the complexity of the software system to be developed!
Reducing Complexity: Coupling and Cohesion
The architect of a concert hall endeavors to build the hall in such a way that the acoustic disturbance from outside is extremely low, the audibility inside the hall is extremely high.
In the software architect's work, this corresponds to the division into modules in such a way that minimizing the coupling (i.e. the width and complexity of the interfaces) between the modules, the cohesion (i.e. the relationship between the parts of a module) is as high as possible.
Complexity Reduction Principles
Separation of concerns
Combine relevant architectural concerns and responsibilities into groups of related functions, e.g. authentication, DB management, system monitoring, etc.
Single responsibility principle: A component is responsible only for one task.
Don't repeat yourself
Do not duplicate any functionality, this makes maintenance more difficult.
Ensure stable (small) interfaces
Changes to interfaces mean that all components that implement this interface may have to be changed.
Complexity Reduction - Hierarchical Structure
The hierarchical structure is a proven method of reducing complexity.
A hierarchy is a structure of elements that are ranked by a (hierarchy-forming) relationship.
Complexity Reduction - Hierarchy Types
Aggregation hierarchy:
Organizes a system into its components; it is also called the "whole-part hierarchy".
Layer hierarchy:
Arranges components (layers) in such a way that each layer builds on exactly one layer below it and forms the basis for exactly one layer above it.
Generalization hierarchy:
Organizes components according to characteristics (methods and attributes) by combining fundamental, common characteristics of several components in one universal component.
Specialized components derived from these take over these characteristics and add special ones. This means that the fundamental features are only defined once.
Object-oriented design focuses on generalization hierarchies of classes and interfaces
Layered Architecture for Web-Based Applications
Browser-based/mobile interfaces
Authentication and UI management
Application-specific functionality
Common basic services
Transaction and database management
A layer combines components that logically belong together.
A layer provides services that are offered at the (upper) interface of the layer.
If strictly layered: The services of a layer can only be used by components of the layer directly above it.
Changes in a layer should only affect the layers above it, but not the layers below.
If strictly layered: Layers are built (directly) on top of each other; access through several layers is not permitted.
Layers are only coupled if they are adjacent. However, this coupling is also low due to the encapsulation of the operations. Changes therefore usually only have a local effect (within a layer).
Cross-Cutting Concerns
Some responsibilities are "cross-cutting" and must be considered in each layer. Examples: Security, performance, reliability.
Typical quality features are CCC Cross-Cutting Concerns.
Example: Security attacks can happen at any level Protection mechanisms must be implemented at every level.
Layered Architecture Example Breakdown
Browser-based/mobile interfaces E.g. web browser interfaces, JavaScript components for local actions, e.g. input validation, e.g. input validation amount.
Management layer for the user interface, components for authentication, creation of web pages, etc., authentication, structure of screens, pages
Application layer. This is where the "business logic" takes place, e.g. transferring money, displaying account balances, creating standing orders, etc..
Reuse of basic functionalities required by the application layer, e.g. customer, account.
Database layer, which provides services such as transaction management and recovery, persistence layer.
Three-Layer Architecture
Many interactive software systems are made up of the following three layers:
Presentation layer,
Application layer and
Data storage layer.
The presentation layer implements the user interface, displays information and controls the user-system interaction.
The application layer contains all components that implement the technical functionality. They are designed in such a way that they do not contain any information about the presentation.
Below this is the data storage layer. It ensures permanent storage, usually in a database. Storage details are hidden in this layer!
Further Principles
KISS
Keep it simple and stupid
(Originally: Keep it short and simple)
What does that mean?
Why is it important?
Abstraction
The basis of many design principles is abstraction.
By creating abstractions, we concentrate on the essentials and ignore the non-essentials.
The Open/Closed Principle
Open for expansion, closed for change
Extensions can be made without having to change existing code
Design Patterns
Architecture patterns: offer solutions for non-trivial problems at the level of the course granular design (architecture in the narrower sense) of components. (e.g. layer architecture, client-server architecture, MVC model-view-controller)
Design patterns: offer solutions for non-trivial problems at the level of detailed component design.
Both are formulated independently of a specific language, but are usually based on object-oriented concepts.
Design Patterns Advantages
The design patterns give us the opportunity to use our experience and implement tried-and-tested solutions.
They help us to consider non-functional design, such as maintainability or reusability, in the architectural design.
They create a vocabulary for the design and facilitate documentation and communication about architectures.
They can be used as an analysis tool when reengineering existing software.
Warning: Understanding a design pattern is easy. However, you need a lot of design experience to use the patterns sensibly
Libraries
From the application's point of view, the classes of a library are used directly, or the classes of the application inherit from the library classes.
A class library consists of a set of classes that are reusable and offer generally usable functionality, i.e. independent of the application context.
Frameworks
A framework is an architecture of class hierarchies that provides a general generic solution for similar problems in a specific context. Züllighoven (2005)
If very similar applications are developed repeatedly, the applications should be developed on the basis of a generic solution.
A framework has defined interfaces at which the generic solution can be extended with application-specific code.
UI frameworks, test frameworks, etc.
Frameworks rely heavily on the inversion of control principle.
Quality and Architecture
The quality of the architecture significantly determines the quality and costs of the developed system, and does so in the long term.
Therefore:
Prioritize quality requirements
Carry out architecture reviews
Evaluate the extent to which the quality requirements are met
Document the WHY of an architectural decision
Object-Oriented Analysis and Design
Means finding functional units and designing (classes) in such a way that they represent the relevant units and concepts of the application area under consideration (=part of the reality to be modeled).
Central activities of object-oriented design:
Identifying objects and classes
Defining the behavior of objects and classes
Identifying relationships between the classes
Defining the interfaces between the classes
The design is based on the (object-oriented) current state analysis, which aims to identify the technical processes and model them in the form of use cases and describe the units using an object-oriented conceptual model.
Task Questions
Why is it important to minimize the complexity of a system?
An architecture that takes security aspects into account can either be based on a centralized model, in which all sensitive information is stored in one place, or on a distributed model, in which information is distributed everywhere and stored in many different places. Write down one advantage and one disadvantage of each solution.
What is the Separation of Concerns principle?
Summary
Architecture decisions have an enormous influence on the quality characteristics of a software system.
Quality features influence each other, there is no "perfect architecture" that fulfills ALL quality features equally. Prioritization of the quality design is important!
Architecture has an influence on the complexity of the software system to be developed!
In order to reduce complexity, a high degree of cohesion within the components (packages, modules, classes) and loose coupling between them must be ensured.
Principles provide guidelines on how complexity can be reduced.
Design patterns exist at different levels of abstraction.