Software abstraction and modelling Flashcards
Software design
The activity of constructing models representing:
- abstractions of data and computation
- the organization of these abstractions into a working
software system
Features of a good model
- mapping feature: a model is based on an original (=system)
- reduction feature: a model only reflects a (relevant) selection of the original‘s properties
- pragmatic feature: A model needs to be usable in place of an original with respect to some purpose
who does what
picture
descriptive <-> prescriptive
subject is described by <-> prescribes the subject
descriptive models
Sketches and throw-away models
- to better understand reality and to explore possible solutions
- short lifetime (usually)
- Models of ideas and vision about the system to be developed
- to exploit the model for having feedback before implementing the system
- Models extracted from a running system or source code
- for example, to visualise all possible calls between a set of
Java classes
prescriptive models
- They guide the development of the system
- more detailed than descriptive models
- specify constraints for the system
- Common consumers of prescriptive models are developers or code generators (model-driven engineering - MDE)
- Prescriptive models are often used for development
- their importance might decrease when the system is implemented
informal notations
- Ad-hoc visualizations with no clear semantics
- Examples: “box-and-line” or PowerPoint diagrams
semiformal notations
- Standardised graphical elements and construction rules, semantics are mostly specified to allow basic analysis
- Examples: UML (we will use it extensively in this course)
formal
- Precise semantics based on mathematical constructs that allow full formal analysis for syntax and semantics
- Examples: architecture description languages (ADLs), e.g., Acme, AADL, AUTOSAR
Software design vs. software architecture
- Software design is the activity of creating an architecture
- Software architecture is concerned with high-level, coarse-grained structures and decisions of a system
- Software design is concerned with more local, fine-grained structures and decisions
Why do we need (architecture and) design?
- They enable reasoning about large systems
→ abstractions and hierarchies help to manage complexity - They are the driver for software quality (not what the system does, but how it does it)
- They enable separating a system into parts to let teams work on them in parallel
- They are the bridge between the requirements and the implementation