Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Analytical Modeling of Software - Lecture Slides | CSE 335, Study notes of Computer Science

Material Type: Notes; Class: Software Design; Subject: Computer Science & Engineering; University: Michigan State University; Term: Unknown 1989;

Typology: Study notes

Pre 2010

Uploaded on 07/22/2009

koofers-user-pkh-1
koofers-user-pkh-1 🇺🇸

4

(1)

10 documents

1 / 5

Toggle sidebar

Related documents


Partial preview of the text

Download Analytical Modeling of Software - Lecture Slides | CSE 335 and more Study notes Computer Science in PDF only on Docsity! 1 CSE 335: Software Design K. Stirewalt Analytical modeling of software Lecture 1: Alloy a language for representing pure abstractions Before we meet again: – Read: Jackson Chapters 1 and 2 – Read: “No Silver Bullet” paper – Download and install Alloy analyzer (version 4) on your home PC and play with the examples CSE 335: Software Design K. Stirewalt Analytical modeling notation Working definition: Design notation with a formal syntax and semantics and whose features were chosen to enable automated analysis of models written in the notation Implies means for “executing” or automatically verifying properties of a model What good are these? – Provide simple and precise means for expressing pure abstractions (who cares? See Brooks paper) – Provide massive “bang for the buck” relative to more declarative less automatable notations CSE 335: Software Design K. Stirewalt Why model a design? “I conclude there are two ways of constructing a software design. One way is to make it so simple there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.” Tony Hoare [Turing Award Lecture, 1980] “Plan to throw one away; you will anyhow.” F. P. Brooks CSE 335: Software Design K. Stirewalt Imperative vs. declarative The more you add, the less happens Good for partial description Good for incremental modeling anything can happen nothing can happen … CSE 335: Software Design K. Stirewalt The Alloy analyzer Alloy installed on Adriatic – soft/linux/bin/alloy – models in soft/linux/alloy/models Or, download to your home machine Alloy: – Go to http://alloy.mit.edu – Choose “Alloy 4” – double click alloy.jar or – execute java -jar alloy.jar at the command line CSE 335: Software Design K. Stirewalt The Alloy language Inspired by Z notation but with fundamental concessions made to support analysis and several “modeling idioms” – E.g., only first-order relations – No built-in distinction between scalars and sets – a few others... Has an object- oriented look and feel, but also provides support for relational modeling No primitive datatypes (e.g., integers) 2 CSE 335: Software Design K. Stirewalt Consider an e-mail address book As a running example, we will begin to model an address book in an e- mail client – Address books should map aliases (e.g., joe, mary) to e-mail addresses to simplify message composition – Eventually, we want to model support for group aliases (e.g., cse814students) CSE 335: Software Design K. Stirewalt First model of address book sig Name, Addr {} sig Book { addr: Name -> lone Addr } This model comprises three sets (Name, Addr, and Book) and one relation (addr) CSE 335: Software Design K. Stirewalt First model, one line at a time sig Name, Addr {} This line introduces two sets (Name and Addr) – Sets are opaque and disjoint – Names suggest their meaning, but model says nothing about the structure of objects in these sets Question: Why aren’t we saying more, e.g., elements of Name are strings, or that elements of Addr are records with account, domain, etc? CSE 335: Software Design K. Stirewalt Virtue/necessity of abstraction Answers: – Internal representation of name (resp. address) objects is irrelevant for the purposes of this model – Analytical model must abstract in every way possible so as to avoid state explosion during analysis How a designer chooses to abstract affects the contents/complexity of the resulting model Tip: Clearly understand your reasons for modeling before you write a line of Alloy! CSE 335: Software Design K. Stirewalt Signature declaration A signature declaration – defines a set of objects – may also declare relations – may (or may not) define a new type Top- level signatures introduce disjoint sets First line of our declares that Name objects are distinct from Address objects (i.e., sets do not overlap) In fact, Name and Address are different types (more later) CSE 335: Software Design K. Stirewalt First model, one line at a time sig Book { addr: Name -> lone Addr } Introduces new set (Book) and relation (addr) A relation is declared as a field in a signature – declaration sig A { f : e } – introduces relation f whose domain is A and range given by the expression e
Docsity logo



Copyright © 2024 Ladybird Srl - Via Leonardo da Vinci 16, 10126, Torino, Italy - VAT 10816460017 - All rights reserved