System Models I: Luca Viganò

System Models I
Luca Vigan
Dipartimento di Informatica Universit di Verona
Ingegneria del SW, 23.03.11
Luca Vigan (Universit di Verona)
System Models I
1 / 82
Objectives
To explain why the context of a system should be modeled as part of the requirements engineering process. To describe behavioral modeling, data modeling, and object modeling. To introduce some of the notations used in the Unied Modeling Language (UML). To show how CASE workbenches support system modeling.
See: Ian Sommerville. Software Engineering. Pearson Education Ltd.
System Models I
2 / 82
Table of contents
1 2
The context: what is modeling? System modeling: perspectives and models Context models Behavioral models Data-processing models State-machine models Semantic data models Object models Structured methods and CASE workbenches Conclusions Example solution of the last homework New homework Appendix: Notazione estesa per diagrammi ERA
System Models I Ingegneria del SW, 23.03.11 3 / 82
3 4 5 6 7
The context: what is modeling?
Outline
1 2
3 4 5 6 7
The context
Requirements analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance
Goal: Specify the requirements as far as possible, but as abstractly as possible. Modeling languages and methods are used here!
Luca Vigan (Universit di Verona) System Models I Ingegneria del SW, 23.03.11 5 / 82
Requirements Engineering: Overview
System Models I
6 / 82
Requirements Elicitation vs. Analysis

Requirements specication and analysis model represent the same information. Requirements Elicitation
Denition of the system in terms understood by the customer. Requirements specication uses natural language. Communication with clients and users.
Analysis
Technical specication of the system in terms understood by the developer. The analysis model uses a formal or semi-formal notation. Communication among developers.
System Models I
7 / 82
Analysis model
System Models I
8 / 82
What is modeling?
Goal: Specify the requirements as far as possible, but as abstractly as possible. Building an abstraction of reality.
Abstractions from things, people, and processes. Relationships between these abstractions.
Abstractions are simplications.

They ignore irrelevant details. They represent only the relevant details. What is relevant or irrelevant depends on the purpose of the model.
Draw complicated conclusions in the reality with simple steps in the model.
System Models I
9 / 82
Example 1: cat
System Models I
10 / 82
Example 2: street maps
System Models I
11 / 82
Example 3: Atom models in physics
System Models I
12 / 82
System modeling
A model is a construction or mathematical object that describes a system or its properties. Examples:
From physics: distance = speed time. A construction engineer models buildings and employs static models (e.g., of stress and strains) for their analysis.
In computer science, we model systems, their operating environment, and their intended properties.
These models aid requirements analysis, design, and analysis of systems.
The construction of models is the Raison-dtre of planning. = research on modeling languages and modeling methodologies. Motto: Engineers build models, so should software engineers!
Why model software?
Software is getting increasingly more complex.

Windows 2000: 40 millions lines of code. A single programmer cannot manage this amount of code in its entirety.
Code is not easily understandable by developers who did not write it. We need simpler representations for complex systems. Modeling is a means for dealing with complexity.
System Models I
14 / 82
What is a good model?

Intuitively: A model is good if relationships, which are valid in reality R , are also valid in model M . Interpretation I : R M . M O

fR I fM
/M O I /R
I : mapping of real things in reality R to abstractions in model M . fM : relationship between abstractions in M . fR : relationship between real things in R .
In a good model, this diagram is commutative.
System Models I
15 / 82
Models of models of models of...
System Models I
16 / 82
Modeling the real world
System Models I
17 / 82
Modeling example: data modeling
System Models I
18 / 82
Modeling example: object modeling
System Models I
19 / 82
System modeling: perspectives and models
Outline
1 2
3 4 5 6 7
System modeling helps the analyst to understand the functionality of the system and models are used to communicate with customers. Different models present the system from different perspectives. External perspective showing the systems context or environment. Behavioral perspective showing the behavior of the system. Structural perspective showing the system or data architecture.
System Models I
21 / 82
Model types
Data-processing model showing how the data is processed at different stages. Composition model showing how entities are composed of other entities. Architectural model showing principal subsystems. Classication model showing how entities have common characteristics. Stimulus/response model showing the systems reaction to events.
System Models I
22 / 82
Which modeling language?

There are hundreds! Differences include: System view: static, dynamic, functional, object-oriented,... Degree of abstraction: e.g. requirements versus system architecture. Formality: Informal, semi-formal, formal. Methodology: OO (OOA/OOD, OMT, Fusion, UML), algebraic specication, Z/CSP, HOL,... Examples: Function trees, data-ow diagrams, ERA diagrams, syntax diagrams, data dictionaries, pseudo-code, rules, decision tables, (variants of) automata, Petri-nets, class diagrams, CRC-cards, message sequence charts,...
System Models I
23 / 82
Methodologies often mix languages

Z/CSP: (Communicating Sequential Processes) 2 models: functional and dynamic/event oriented. 2 languages. OMT: Object Modeling Technique. 3 models: object, dynamic, functional. 3 languages: class diagrams, statecharts, data-ow diagrams. Unied Modeling Language: 9 languages: class, object, use cases, sequence, collaboration, statecharts, activities, component, and deployment. Let us look at some example models and methodologies.
System Models I
24 / 82
Context models
Context models
Context models are used to illustrate the operational context of a system: they show what lies outside the system boundaries. Social and organizational concerns may affect the decision on where to position system boundaries. Architectural models show the system and its relationship with other systems. For example: the context of an ATM system
System Models I
26 / 82
Context models
Context models (cont.)

Architectural models describe the environment of a system, but they do not show the relationships between the other systems in the environment and the system that is being specied. External systems:
Might produce data for or consume data from the system. Might share data with the system, or they might be connected directly, through a network or not at all. Might be physically co-located or located in separate buildings.
All of these relations might affect the requirements of the system being dened and must be taken into account. Hence, simple architectural models are normally supplemented by other models, such as
process models that show the overall process and the processes that are supported by the system, and data models (see below) that show the processes and the ow of information from one process to another.
Context models
Process models
Process models show the overall process and the processes that are supported by the system. For example: equipment procurement process
System Models I
28 / 82
Behavioral models
Behavioral models
Behavioral models are used to describe the overall behavior of a system. Two types of behavioral model are: Data-processing models that show how data is processed as it moves through the system. State-machine models that show the systems response to events. These models show different perspectives so both of them are required to describe the systems behavior.
System Models I
30 / 82
Data-processing models
Data-processing models: DFD

Recall: data-ow diagrams DFD are a graphical specication language for functions and data-ow. Based on symbols, but not standardized indeed, here is a slightly different notation than the one we saw:
Function
Input Data Flow
Output Data Store
Useful for requirements plan and system denition. Provides a high-level system description that can later be rened.
Example: library information system

Book Request by User Book Title/Author and User Name Get a Book Book Book Reception Book title, user name Search by Topic List of books borrowed List of titles Display of list of titles
Book Shelves Author Title List of Authors
List of titles List of topics
Title Topic
Topic Topic Request by User
First approximation. Unspecied how books are found, etc.

Partial DFD-Renement
Book Shelves Get a Book Author List of Authors Title List of titles Book Book Reception
<shelf#, book#> Find Book Position
List of books borrowed Book title, user name
Book Title/Author and User Name Book Request by User
Describes how a book is selected.

Still inexact. Are both title and name needed? Semantics suggested by the function names. Control open. Execution scheduling is not specied.
Hierarchical DFDs & development methods

DFDs yield a module structure:
M B A M1 C
Procedure M calls either M 1 once or M 2 multiple times. M passes B to M 1 and receives A back, and M receives C from M 2.
M2
Example: architecture of the module order book
Deliver Book Book <shelf#, book#> Find Book Position Author Title <shelf#, book#> Get a Book
Can be supported by CASE-tools, e.g. for the automatic generation of classes or (module) signatures.
State-machine models
State-machine models model the behavior of the system in response to external and internal events. They show the systems responses to stimuli, so are often used for modeling real-time systems. State-machine models show system states as nodes and events as arcs between these nodes. When an event occurs, the system moves from one state to another. Statecharts are an integral part of the UML and are used to represent state-machine models.
System Models I
37 / 82
Allow the decomposition of a model into submodels, e.g. microwave oven model:
A brief description of the actions is included following the do in each state. Can be complemented by tables describing the states and stimuli.
Microwave oven state & stimuli descriptions
STATE Waiting Half power Full power Set time Disabled Enabled Operation
STIMULUS Half power Full power Timer Number Door open Door closed Start Cancel
DESCRIPTION The oven is waiting for input. The display shows the current time. The oven power is set to 300 watts. The display shows Half power. The oven power is set to 600 watts. The display shows Full power. The cooking time is set to the users input value. The display shows the cooking time selected and is updated as the time is set. Oven operation is disabled for safety. Interior oven light is on. Display shows Not ready. Oven operation is enabled. Interior oven light is off. Display shows Ready to cook. Oven in operation. Interior oven light is on. Display shows the timer countdown. On completion of cooking, the buzzer is sounded for 5 seconds. Oven light is on. Display shows Cooking complete while buzzer is sounding. DESCRIPTION The user has pressed the half power button. The user has pressed the full power button. The user has pressed one of the timer buttons. The user has pressed a numeric key. The oven door switch is not closed. The oven door switch is closed. The user has pressed the start button. The user has pressed the cancel button.
System Models I
39 / 82
Microwave oven operation
System Models I
40 / 82
Semantic data models

Most large software systems make use of a large database of information. Semantic data models describe the logical structure of data processed by the system. Most widely used data-modeling technique is Entity-Relationship-Attribute (ERA) modeling, which shows
the data entities, their associated attributes, and the relations between these entities.
Often called Entity-Relationship (E/R) diagrams. Widely used in database design (cf. relational databases). No specic notation provided in the UML but objects and associations can be used.
Entity-Relationship-Attribute (ERA) Modeling
Species sets of (similar) data and their relationships. Relationships are typically stored as tables in a data-base. Three kinds of objects are visually specied:
Entities: sets of individual objects, differing in their properties. Attributes: a common property of all objects in an entity set. Relations: (semantic) relationships between entities.
System Models I
43 / 82
ERA example
Student & Course entities

A Student has a name, age, and identity. A Course has a subject and course_id. In programming languages: attributes basis types, entities record types. type Student type Course = student (name : string , age : N, id : N) = course(subject : string , course_id : string )
Student name age id enrolled_in subject Course course_id
Relations are graphically represented, e.g. Student enrolled_in Course
ERA: a larger example (without attributes)
boss of
is employed by is project leader on leads is out of stock project
is ill
employee
belongs to divison
uses part delivers supplier
System Models I
45 / 82
ERA: advantages and disadvantages

++ 3 concepts and pictures = easy to understand. ++ Tool supported and successful in practice. Not (really) standardized.
Are relations binary or n-ary? OO extensions (e.g. is_a)? Notation for semantic conditions? For example, R is injective: x x y .(x R y x R y ) x = x
Many relations cannot be specied. Every n-ary function corresponds to an n+1-ary relation. For more, see data-base classes (and the appendix of these slides).
An example semantic model: LIBSYS
LIBSYS is designed to deliver copies of copyrighted articles that have been published in magazines and journals, and to collect payments for these articles. Hence, data model must include information about the article, the copyright holder, and the buyer of the article (payments are assumed to be made not directly, but through national copyright agencies).
An example semantic model: LIBSYS
An Article has attributes representing the title, the authors, the name of the PDF le of the article, and the fee payable. Linked to the Source, where the article was published, and to the Copyright Agency for the country of publication. Both Copyright Agency and Source are linked to Country. The country of publication is important as copyright laws vary by country. The diagram also shows that Buyers place Orders for Articles.
Data dictionaries
Like all graphical models, data models lack detail, and one should maintain more detailed descriptions of the entities, relationships, and attributes that are included in the model. Such a description can be collected in a repository or data dictionary: Data dictionaries are lists of all of the names used in the system models. Descriptions of the entities, relationships and attributes are also included. Advantages:
Support name management and avoid duplication. Serve as a store of organizational knowledge linking analysis, design, and implementation.
Many CASE workbenches support data dictionaries.

Data dictionary entries for LIBSYS

Name Article authors Buyer fee-payable-to Description Details of the published article that may be ordered by people using LIBSYS The names of the authors of the article who may be due a share of the fee The person or organization that orders a copy of the article A 1:1 relationship between Article and the Copyright Agency who should be paid the copyright fee The address of the buyer. This is used to any paper billing information that is required. Type Entity Attribute Entity Relation Date 30.10.2006 30.10.2006 30.10.2006 29.10.2006
Address (Buyer)
Attribute
31.10.2006
System Models I
50 / 82
Object models
Object models
Object models describe the system in terms of object classes and their associations. An object class is an abstraction over a set of objects with common attributes and the services (operations) provided by each object. Various object models may be produced:
Inheritance models. Aggregation models. Interaction models.
System Models I
52 / 82
Object models
Object models (cont.)
Natural ways of reecting the real-world entities manipulated by the system. More abstract entities are more difcult to model using this approach. Object class identication is recognized as a difcult process requiring a deep understanding of the application domain. Object classes reecting domain entities are reusable across systems.
System Models I
53 / 82
Object models
Inheritance models
Organize the domain object classes into a hierarchy. Classes at the top of the hierarchy reect the common features of all classes. Object classes inherit their attributes and services from one or more superclasses. These may then be specialized as necessary. Class hierarchy design can be a difcult process if duplication in different branches is to be avoided.
System Models I
54 / 82
Object models
Object models and the UML
The UML is a standard representation devised by the developers of widely used object-oriented analysis and design methods. It has become an effective standard for object-oriented modeling. Notation:
Object classes are rectangles with the name at the top, attributes in the middle section and operations in the bottom section. Relationships between object classes (known as associations) are shown as lines linking objects. Inheritance is referred to as generalization and is shown upwards rather than downwards in a hierarchy.
System Models I
55 / 82
Object models
For example: Class models (High-Level)

Emphasis: objects and relationships. Goal: clarity and reusability. Objects are grouped into classes depending on their attributes and methods.
(House) House type: Land house Owner: P. Rossi Address: Caselle Area: 400 [qm] # baths: 3 Pool?: Yes Garten: 5000[qm] Year built: 1976 Sales price: 1.5 Mio.[Euro] Ask sales price
(House) House type: Bungalow Owner: G. Bianchi Address: Lazise Area: 250 [qm] # baths: 2 Pool?: No Garten: 1500[qm] Year built: 1986 Sales price: 1 Mio.[Euro] Ask sales price
(House) House type: City house Owner: G. Verdi Address: Verona Area: 200 [qm] # baths: 2 Pool?: No Garten: 400[qm] Year built: 1990 Sales price: .8 Mio.[Euro] Ask sales price
Class hierarchy formalizes inheritance, expresses shared attributes/methods. Generalizes ERAs. More in next lectures.
House House type Area # baths Pool? Garten
Property Owner Address Year built Sales price Ask sales price
Buro # buro rooms # floors Elevator? Parking Garage? Ask # rooms
System Models I
56 / 82
Structured methods and CASE workbenches
Outline
1 2
3 4 5 6 7
Structured methods
A structured method is a systematic way of producing models of an existing system or of a system that is to be built. Structured methods provide a framework for detailed system modeling as part of requirements elicitation and analysis. Methods dene a set of models, a process for deriving these models, and rules and guidelines that should apply to the models. They have some weaknesses, though:
They do not model non-functional system requirements. They do not usually include information about whether a method is appropriate for a given problem. The may produce too much documentation. The system models are sometimes too detailed and difcult for users to understand.
CASE tools support system modeling as part of a structured method.

CASE workbenches
A coherent set of tools that is designed to support related software process activities such as analysis, design, or testing. Analysis and design workbenches support system modeling during both requirements engineering and system design. These workbenches may support a specic design method or may provide support for creating several different types of system model.
System Models I
59 / 82
An analysis and design workbench

Data dictionary Structured diagramming tools Central information repository Design, analysis and checking tools Report generation facilities Query language facilities
Code generator
Forms creation tools
Import/export facilities
Components:
Diagram editors. Model analysis and checking tools. Repository and associated query language. Data dictionary. Report denition and generation tools. Forms denition tools. Import/export translators. Code generation tools.
Conclusions
Outline
1 2
3 4 5 6 7
Conclusions
Key points
A model is an abstract system view. Complementary types of model provide different system information. Context models show the position of a system in its environment with other systems and processes. Data-ow models may be used to model the data processing in a system. State-machine models model the systems behavior in response to internal or external events. Semantic data models describe the logical structure of data which is imported to or exported by the systems. Object models describe logical system entities, their classication and aggregation. Sequence models show the interactions between actors and the system objects that they use. Structured methods provide a framework for developing system models.
Example solution of the last homework
Outline
1 2
3 4 5 6 7
The Project
Development of a scheduling Class Scheduling System CSS for an educational institution, e.g. the Department of Computer Science of the University of Verona.
1
Assume the role of the client (or customer, i.e. the university), and write a problem (project) description. Among others, the description should address the following issues: Who will use the system? Who will/should administer the system? Which functionalities (input, output) should the system have? In which computer environment should the system work? Who could act as an expert, i.e. who is available to provide further information (and answer possible questions of the contractor about the project to be developed)? Which acceptance criteria (which kind of tests) should the system satisfy?
Assume the role of the contractor (i.e. provider, or system architect ) and, on the basis of the problem description, start the Analysis&Denition phase by giving a detailed analysis of the requirements and by writing a detailed and structured product (project) sketch.
Problem Description of the Client. The goal of this project is to develop a scheduling system for classes at a university. The system must generate and distribute timetables according to data containing event-offers (i.e. offers of courses, exercises, seminars, etc., given by the teaching staff), room capacities and general constraints. The system must also provide editing facilities for the maintenance of this data. The system must interact with the following users: The scheduling manager or coordinator, an administrative person who controls the system (i.e. the core software component). The teaching staff or the secretaries of the different chairs, who register the various event-offers. The administration, which provides the registration of rooms and their features and capacities. External users (students, administrative and teaching staff), who can request timetables for classes and rooms via generated web-pages.
System Models I
65 / 82
The generation of the schedules has to respect the following additional requirements: No room should be scheduled with two or more classes at the same time. No instructor (i.e. teaching staff member) should be scheduled to teach two or more classes at the same time. Preferred or proposed times of a class (composed by class-number, instructors and name of the class) and possible room preferences should be respected. Note that a class may consist of several units to be held at (xed) times at different days (e.g. software architectures Mondays from 09:30 to 11:30 and Thursdays from 14:30 to 16:30). Timetables of major and minor subject combinations (corsi mutuati as scheduled by the curriculum) should be respected. The absence of time overlaps has to be guaranteed for major subjects as scheduled in the curriculum. All other classes should not overlap if possible. Excessive distances between the class-rooms should be avoided. The core software component should allow changes of the class/time schedules by hand; possibly by exploiting hints given by the users.
System Models I
66 / 82
Standards in system failure safety and legislative standards in data condentiality have to be respected. The system has to be integrated into the existing faculty network consisting of LINUX-workstations. The data for two schedules of previous semesters should serve as acceptance test: with the assistance of the installed system, it should be possible for the scheduling manager to generate schedules of comparable quality. For the rst year, the contractor should provide the installation of the system, maintenance service and teaching for the major users of the system. Afterwards, a separate maintenance contract will be concluded. The precise date of delivery and a detailed cost plan will be treated in a separate document. For further questions, contact the headmaster Mr. XXX.
System Models I
67 / 82
Analysis of the Requirements by the contractor A few days later, a consultant of the contractor arranges an interview with the headmaster Mr. XXX. A very brief analysis of the original problem description revealed some points that must be claried or negotiated. Here is a brief summary of the interview. Consultant: Do excessive distances between the class-rooms represent a problem? This could namely be quite difcult to cope with. Mr. XXX: Well, we are a closed campus, and anyway, in practice, data from other campuses will be difcult to achieve in time. So you may neglect the problem and defer it to a later version. Consultant: It says that Standards in system failure safety and legislative standards in data condentiality have to be respected. What does this mean precisely? Mr. XXX: All data involved is already publicly available. Our legal advisor came to the conclusion that this does not represent a problem here. Consultant: What exactly is the expected role of the scheduling manager? Purely administrative (implying the system must be fully automatic which may be difcult for complexity reasons) or may he/she control the planning process (implying the system must be interactive and provide a model of high-level interaction)?
Mr. XXX: Our secretary Mrs. BBB arranges the class-schedules by hand at the time being. She is willing to serve as scheduling manager (coordinator) actually she initiated this project. In the past, she tried to nd variants of possible schedules and to gradually improve them. The system should essentially support her in this task. Consultant: What happens if no plan solves all conicts? Mr. XXX: That was always a problem. Maybe the scheduling manager may negotiate with instructors by mail in order to avoid the worst conicts... Consultant: Must the administration have access to the scheduling system or will it sufce that the schedules are communicated to the scheduling manager by email or other means? Mr. XXX: The latter will do. Conclusion: Ignore the distance problem and the data condentiality problems. The key issue is the scheduling manager; its crucial that she is satised, otherwise the project wont be considered as a success. This means that the system must essentially be incremental and handle incremental versions of class-schedules.
System Models I
69 / 82
Product Sketch of the Contractor The following sections are structured according to the scheme presented in the slides. Section I: Problem Description and Objectives of the Project For the computer science department of the University of Verona, the contractor will develop and deploy a system for the semi-automatic generation of class-schedules for each term. Primary goals are: Development of a central program that is embedded in a standard Internet infrastructure. This program will be controlled by one person (the scheduling manager ). Increase of effectiveness and reliability of the planning and scheduling process at the department by the automatic generation of partial class-schedules, which should be as conict-free with respect to the scheduling requirements (see below) as possible. Enabling effective planning by choosing the best partial class-schedules and their incremental completion. The core software component comprising the data base management facilities, the (interactive) planner, and the generator of web-pages etc. is called CSS (class-scheduling system) in the sequel.
Section II: Functionality/External Behavior The core-system is directly controlled by the scheduling manager. He/She reads and edits data bases for rooms and event-offers and produces a version of a general class-schedule. The class-schedule can be read by other users via Internet browsers. The latter may also offer advanced searching and viewing capabilities. Input Input of a proposed class (lecture, lab, seminar) by the instructor (teaching staff; i.e. lecturer and possibly other assistants) as in the problem description above. name of class, names of the instructors, additional information (kind of class, status, priority), requirements (beamer, overhead projector, computer, etc.), estimated number of participants, number of class-meetings and (variants of) their scheduling over the week, possible dates (day/begin/duration). Input and maintenance of the above data by the scheduling manager. Obvious xed constraints for dates, rooms, instructors and proposed classes.
Processing CSS should be able to produce (sub-)optimal class-schedules, i.e. class-schedules that satisfy all constraints (see above). Within the given choices, a maximum of the following requirements should be respected. Scheduling Requirements No room should be scheduled with two or more classes at the same time. No instructor should be scheduled to teach two or more classes at the same time. Preferred or proposed times of a class (composed by class-number, instructors and name of the class) and possible room preferences should be respected. Classes may consist of several units to be hold at different days. Timetables of major and minor subject combinations should be respected. The freeness of time overlaps for major subjects as scheduled in the curriculum has to be guaranteed. All other classes should not overlap if possible. The core software component should allow changes of the class/time schedules by hand; possibly by exploiting hints given by the users. Output Presentation of not solvable conicts against scheduling requirements. Alternatives for solving conicts, if possible. Views for individual persons (instructor, students, other). HTML-pages and PDF-les for the Internet and printout of the nal class-schedule sorted by rooms, instructors, etc.
Section III: User Prole The users of CSS are the scheduling manager, who has basic IT-capabilities (and who should be able to work with CSS after a basic training), students (Web-Browsing), instructors (Web-Browsing), others (Web-Browsing). Section IV: Acceptance Criteria Correctness: the software should be reasonably reliable. It should not lose data in case of exceptional behavior. The generated schedules should be conform to the constraints. CSS should work on the computers of the faculty network (hence: PCs and Laptops). CSS should be able to produce new variants with a reasonably high degree of automation, leading to signicantly less time consumption as the previous generation of schedules by hand. CSS should be appropriately protected against unwarranted access. CSS must be usable by a person with average knowledge in IT, therefore it should possess a GUI and produce understandable, intuitive output. Comprehensive documentation.
Section V: Development/Deployment/Maintenance and Interfaces CSS will be deployed under LINUX (no support for Microsoft Windows). The graphical user-interface must be based on X-Windows. Deployment and maintenance for n years must be assured. Section VI: Solution Strategies Scheduling will be performed by a global search algorithm (nd the n best solutions). In order to reduce complexity, internal heuristics based on pre-sorting the search space according to priorities must be applied. If this does not sufce, further heuristics that produce sub-optimal solutions may be investigated. Certain constraints (such as the ones arising from the curriculum) wont probably change over a long time and should be built-in into the scheduling algorithm, others like the number and features of rooms may change more often, so that CSS will have to cope with these changes. Moreover, we will have to investigate previous schedules and the potential of their reuse. Section VII: More Information Mr. XXX established the contact with the contractor and will remain the ofcial partner for re-negotiations until the end of the project. Mrs. BBB is the current and future coordinator in charge; discussions over her previous experience in scheduling classes and the future use of the system may be important.
New homework
Outline
1 2
3 4 5 6 7
New homework
New homework
We continue with our Class Scheduling System software-project: we now begin the semi-formal analysis of the requirements (employing semi-formal modeling languages), and set up the organization structure of the project.
1
Give a data-model of the CSS system using an ERA diagram. Give an informal (i.e. in natural language) description of the constraints that data must satisfy. Give an informal (i.e. in natural language) description of the conicts that may occur in class schedules produced by our CSS, and discuss how we could prioritize these conicts?
System Models I
76 / 82
Appendix: Notazione estesa per diagrammi ERA
Outline
1 2
3 4 5 6 7
(Notazione tratta da P. Atzeni, S. Ceri, S. Paraboschi, R. Torlone: Basi di dati. McGraw-Hill.) Il modello ERA un modello concettuale di dati e, come tale, fornisce una serie di strutture, dette costrutti, atte a descrivere la realt di interesse in una maniera facile da comprendere e che prescinde dai criteri di organizzazione dei dati nei calcolatori. Questi costrutti vengono utilizzati per denire schemi che descrivono lorganizzazione e la struttura delle occorrenze dei dati, ovvero dei valori che vengono assunti dai dati al variare del tempo.
System Models I
78 / 82
I seguenti sono alcuni dei costrutti principali del modello ERA: Entit: rappresentano classi di oggetti (fatti, cose, persone, per esempio) che hanno propriet comuni ed esistenza autonoma ai ni dellapplicazione di interesse. Unoccorrenza di unentit un oggetto della classe che lentit rappresenta. Sono rappresentate tramite quadrati. Relazioni: rappresentano legami logici, signicativi per lapplicazione di interesse, tra due o pi entit. Sono rappresentate tramite rombi. I seguenti sono alcuni esempi. La relazione Esame tra le entit Studente e Corso. Le relazioni Residenza e Sede di lavoro tra le entit Impiegato e Citt. anche possibile avere relazioni ricorsive, ovvero relazioni tra unentit e se stessa, come la relazione ricorsiva Collega sullentit Impiegato, che connette coppie di impiegati che lavorano insieme.
Studente Esame Corso Sede di lavoro Impiegato Collega Residenza Citta
Impiegato
Attributi: descrivono le propriet elementari di entit o relazioni che sono di interesse ai ni dellapplicazione. Sono rappresentati tramite ellissi o tramite frecce con punta tonda. Ad esempio:
Matricola Studente Anno di iscrizione Sede di lavoro Cognome Stipendio Eta Data di nascita Impiegato Residenza Citta Numero di abitanti Nome Voto Esame Data esame Nome Corso Anno di corso
Un attributo associa a ciascuna occorrenza di entit (o relazione) un valore appartenente a un insieme, detto dominio, che contiene i valori ammissibili per lattributo. I domini non vengono riportati nello schema, ma sono generalmente descritti nella documentazione associata.
anche possibile rappresentare la cardinalit delle relazioni: vengono specicate per ciascuna partecipazione di entit a una relazione e descrivono il numero minimo e massimo di occorrenze di relazione a cui una occorrenza dellentit pu partecipare. Per esempio, se in una relazione Assegnamento tra le entit Impiegato e Incarico specichiamo per la prima entit una cardinalit minima 1 e una cardinalit massima 5, vogliamo indicare che un impiegato pu partecipare a un minimo di unoccorrenza e a un massimo di 5 occorrenze della relazione Assegnamento. Cio, a un impiegato deve essere assegnato almeno un incarico ma non pi di cinque. Se per lentit Incarico specichiamo una cardinalit minima 0 e una cardinalit massima 50, imponiamo che un certo incarico pu participare o a nessuna occorrenza oppure a 50 occorrenze al massimo della relazione Assegnamento. Quindi, un certo incarico pu non essere assegnato a nessun impiegato oppure pu essere assegnato a un numero di impiegati inferiore o uguale a 50.
Impiegato (1,5) Assegnamento (0,50) Incarico
System Models I
81 / 82
In generale, le relazioni possono essere uno a uno: relazioni aventi cardinalit massima pari a 1 per entrambe le entit coinvolte, uno a molti: relazioni aventi unentit con cardinalit massima pari a 1 e laltra con cardinalit massima pari a N, molti a molti: relazioni aventi cardinalit massima pari a N per entrambe le entit coinvolte.
Ordine (0,1) Vendita (1,1) Fattura
Persona
(1,1)
Residenza
(0,N)
Citta
Turista
(1,N)
Prenotazione
(0,N)
Viaggio
N.B.: gli attributi possono essere composti (cio avere a loro volta degli attributi) e avere anchessi una cardinalit.

System Models I: Luca Viganò

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

System Models I: Luca Viganò

Загружено:

Авторское право:

Доступные форматы

System Models I

Ingegneria del SW, 23.03.11

Luca Vigan (Universit di Verona)

Ingegneria del SW, 23.03.11

See: Ian Sommerville. Software Engineering. Pearson Education Ltd.

Luca Vigan (Universit di Verona)

Ingegneria del SW, 23.03.11

Luca Vigan (Universit di Verona)

The context: what is modeling?

Luca Vigan (Universit di Verona)

The context: what is modeling?

The context: what is modeling?

Requirements Engineering: Overview

Luca Vigan (Universit di Verona)

Ingegneria del SW, 23.03.11

The context: what is modeling?

Requirements Elicitation vs. Analysis

Luca Vigan (Universit di Verona)

Ingegneria del SW, 23.03.11

The context: what is modeling?

Luca Vigan (Universit di Verona)

Ingegneria del SW, 23.03.11

The context: what is modeling?

Abstractions are simplications.

Luca Vigan (Universit di Verona)

Ingegneria del SW, 23.03.11

The context: what is modeling?

Luca Vigan (Universit di Verona)

Ingegneria del SW, 23.03.11

The context: what is modeling?

Example 2: street maps

Luca Vigan (Universit di Verona)

Ingegneria del SW, 23.03.11

The context: what is modeling?

Example 3: Atom models in physics

Luca Vigan (Universit di Verona)

Ingegneria del SW, 23.03.11

The context: what is modeling?

The context: what is modeling?

Why model software?

Software is getting increasingly more complex.

Luca Vigan (Universit di Verona)

Ingegneria del SW, 23.03.11

The context: what is modeling?

What is a good model?

In a good model, this diagram is commutative.

Luca Vigan (Universit di Verona)

Ingegneria del SW, 23.03.11

The context: what is modeling?

Models of models of models of...

Luca Vigan (Universit di Verona)

Ingegneria del SW, 23.03.11

The context: what is modeling?

Modeling the real world

Luca Vigan (Universit di Verona)

Ingegneria del SW, 23.03.11

The context: what is modeling?

Modeling example: data modeling

Luca Vigan (Universit di Verona)

Ingegneria del SW, 23.03.11

The context: what is modeling?

Modeling example: object modeling

Luca Vigan (Universit di Verona)