Class Models-Development and Software Engineering-Lecture Slides, Slides of Software Engineering

Download Class Models-Development and Software Engineering-Lecture Slides and more Slides Software Engineering in PDF only on Docsity! Class Models  In this lecture we will be studying Class Models which are a part of the Unified Modeling Language (UML).  Of the various models in UML, we have the categories:  Use case models – describing a system from the users’ point of view;  Static models – describing the elements of the system and their relationship; class models fall into this category;  Dynamic models – describing the behaviour of the system over time. COMP201 - Software Engineering 1 docsity.com A Very Simple Class Model  In the Unified Modelling Language (UML), a class is shown in a class diagram as a rectangle giving its name: 2 COMP201 - Software Engineering docsity.com Deriving Classes  Recall that we previously mentioned the noun identification technique to find potential classes.  There are two main (extreme) techniques used to find classes in general:  Data-driven-design (DDD) – We identify all the data of the system and divide it into classes. We then assign particular responsibilities (methods) to these classes  Responsibility-driven-design (RDD) – We identify all the responsibilities of the system and divide them into classes. We then find the data each class requires. COMP201 - Software Engineering 5 docsity.com Associations  In the same sense that classes correspond to nouns, associations correspond to verbs.  They express the relationship between classes.  There are instances of associations, just as there are instances of classes  Instances of a classes are called objects;  Instances of associations are called links in UML 6 COMP201 - Software Engineering docsity.com Class A and B are Associated if  an object of class A sends a message to an object of class B  an object of class A creates an object of class B  an object of class A has an attribute whose values are objects of class B or collections of objects of class B  an object of class A receives a message with an object of class B as argument 7 In other words, if some object of class A has to know about some object of class B COMP201 - Software Engineering docsity.com Multiplicity We can specify:  an exact number simply by writing it, e.g. 1  a range of numbers using two dots between a pair of numbers, e.g., 1..10  an arbitrary, unspecified number using *  Loosely, you can think of UML’s * as an infinity sign, so the multiplicity 1 .. * expresses that number of copies can be anything between 1 and infinity. 10 COMP201 - Software Engineering docsity.com Attributes and Operations  The attributes of a class describe the data contained in an object of the class and their type  Most important are the operations of a class, which define the ways in which objects may interact. 11 COMP201 - Software Engineering docsity.com Operation Signatures  The signature of an operation gives the selector, names and types of all formal parameters (arguments) and the return type. For example: computeMean(List inputList): Float  Recall that the method called may depend upon a classes position within the inheritance hierarchy. There may be methods with the same name, do you remember the concept of dynamic binding? 12 COMP201 - Software Engineering selector Argument type Argument name Return type docsity.com Generalization  An object of a specialized class can be substituted for an object of a more general class in any context which expects a member of the more general class, but not the other way round 15 COMP201 - Software Engineering Animal Age: Integer getAge(): Integer Cat meow(): void Dog bark(): void docsity.com Generalization 16 COMP201 - Software Engineering Animal Age: Integer getAge(): Integer Cat meow(): void Dog bark(): void Animal any = new Animal(12); any.getAge(); any.meow(); any.bark(); Fine, returns 12 Error – No meow() method! Error – No bark() method! docsity.com Animal any = new Cat(8); any.getAge(); any.meow(); any.bark(); Generalization 17 COMP201 - Software Engineering Animal Age: Integer getAge(): Integer Cat meow(): void Dog bark(): void Fine, returns 8 Fine, object “meows” Error – No bark() method! docsity.com Creating CRC Cards  The name of a class, at the top  The responsibilities of the class, on the left-hand side  The collaborators of the class, which help to carry out each responsibility, on the right-hand side of the card. The responsibilities of the class describe at a high level the purpose of the class’s existence :  They are connected with the operations the class provides, but are more general than that might imply – i.e., they can be an abstraction of several operations. 20 COMP201 - Software Engineering docsity.com CRC Cards  In general there should be one or two responsibilities per class and usually no more than four. Too many responsibilities often signals low cohesion (i.e., a bad level of abstraction) in the system.  Too many collaborators can signify high coupling in the system (the class is connected to too many other classes).  Since we aim to have systems with high cohesion and low coupling, we should aim to find a compromise between these values which is still conceptually sound. 21 COMP201 - Software Engineering docsity.com CRC Card Example 22 COMP201 - Software Engineering Questions: Do these three classes conform to our notion of a good design? What is their level or cohesion and coupling? docsity.com More on Class Models  Aggregation and composition  Roles  Navigability  Qualified association  Derived association  Constraints  Association classes  More about classes  We study these next lecture … 25 COMP201 - Software Engineering docsity.com Lecture Key Points  During this lecture we introduced class diagrams which represent the static (as opposed to the dynamic) nature of the system to be built.  We discussed how classes and their associations can be found and the concept of multiplicity.  We also discussed class attributes and operations as well as looking at representations of generalization.  Finally we used the idea of CRC cards to validate a model. COMP201 - Software Engineering 26 docsity.com