5BUIS017W BIS Design and Architecture PDF

5BUIS017W BIS Design and Architecture LECTURE, WEEK 3 TOPIC(S): ADVANCED MODELLING; CONTROL -ENTITY-BOUNDARY CLASSES; CLASSIFIERS; OBJECT DIAGRAM Content of the presentation In today’s lecture, we’ll cover the following topics: Advanced Modelling Class and design Boundary – Control – Entity...

5BUIS017W BIS Design and Architecture LECTURE, WEEK 3 TOPIC(S): ADVANCED MODELLING; CONTROL -ENTITY-BOUNDARY CLASSES; CLASSIFIERS; OBJECT DIAGRAM Content of the presentation In today’s lecture, we’ll cover the following topics: Advanced Modelling Class and design Boundary – Control – Entity classes; BCE pattern Classifiers: Class, Abstract class, Interface Object diagram 2 Classes – advanced modeling Advanced class modeling Extension mechanisms What is the need of extension mechanisms? Although UML is very well-defined, there are situations in which it needs to be customized to specific problem domains UML extension mechanisms are used to extend UML by: ◦ adding new model elements, ◦ creating new properties, ◦ and specifying new semantics 3 Classes – advanced modeling Extension mechanisms specify “how specific UML model elements are customized and extended with new semantics” by using o Stereotypes: Extend UML for a particular purpose that has to do with design modelling o Comments: Additional explanation attached to a model element o Constraints: Semantic relationship among model elements. o Tags – tagged values A coherent set of such extensions, defined for specific purposes, constitutes a UML profile 4 Classes – advanced modeling: stereotypes Stereotypes are used to extend UML to create new model elements that can be used in specific domains When modeling a system, we may need to represent some classes as “stereotypes” Stereotype: “a widely held image or idea of a a particular type of thing” E.g., o «hardware» o «software» Stereotypes should always be applied in a consistent way Ways of representing a stereotype: o Place the name of the stereotype above the name of an existing UML element (if any) o The name of the stereotype needs to be between «» (e.g. «hardware») 5 Classes – advanced modeling: stereotypes Stereotypes allow you to extend the vocabulary of the UML so that you can create new model elements, derived from existing ones Examples:  Stereotypes can also be used to classify a method / behavior such as , or  To indicate the interface of a subsystem or system, one can use the stereotype Stereotypes can be represented with icons and graphics:  This can increase the readability of UML diagrams.  When the stereotype is applied to the UML design element, the icon is displaced on top or beside the name. 6 Classes – advanced modeling: stereotypes UML has many predefines stereotypes: o Classes: , , , , o Constraints: etc. o Dependencies: , o Comments: , o Packages: , Or, create your own if needed. 7 Classes – advanced modeling: stereotypes Stereotypes extend an existing UML modeling element A stereotype varies the semantics of an existing element (they are not a new model elements per se) Examples: Customer Class “Customer” with as label stereotype Class “Customer” with actor as icon stereotype Customer Class “Customer” with actor as decoration stereotype Customer Class “Customer” with no stereotype Customer 8 Classes – advanced modeling: comments & constraints Constraints are used to extend the semantics of UML by adding new rules, or modifying existing ones Constraint - semantic relationship among model elements that specifies conditions and propositions that must be maintained as true o Constraint text must be enclosed in braces {...} Comments are used to help clarify the models that are being created e.g. comments may be used for explaining the rationale behind some design decisions A comment is shown as a text string within a note icon. Text string attached to a model element (e.g. class) 9 Classes – advanced modeling: comments & constraints Example CONSTRAINT COMMENT 10 Classes – advanced modeling: tags Tagged value - may be attached to any kind of model element o like constraints, tag values represent arbitrary textual information and are written inside curly brackets o unlike stereotypes, tag values are not meant to extend the UML semantics and create new UML profiles o like stereotypes and constraints, few tags are predefined in UML o typical use of tags is in providing project management information 11  Classes – advanced modeling: tagged values Tagged values Define additional properties for any kind of model elements Can be defined for existing model elements and for stereotypes Are shown as a tag-value pair where the tag represent the property and the value represent the value of the property Tagged values can be useful for adding properties about ocode generation oversion control oconfiguration management oAuthorship etc. Note: These tell you something about the model, not about the final system to be built! 12 Classes – advanced modeling: tagged values A tagged value is shown as a string that is enclosed by brackets {} and which consists of: the tag, a separator (the symbol =), and a value Two tagged values {author = “Bob”, Version = 2.5} Employee name address 13 Classes and design The class diagram we have up to this point is mainly the result of the analysis phase (depends on how we have used extension mechanisms). The “analysis class diagram” is only an interim report; It should be realized as a design class diagram; That will be used for the software implementation What kind of information do we miss so far? o The role that each class plays – the responsibilities of each class in relation to the system Do all classes have the same “role”? 14 Classes and design Robustness Analysis Robustness analysis aims to produce set of classes robust enough to meet requirements of a use case Makes some assumptions about the interaction: o Assumes some class(es) is/are needed to handle the user interface o Abstracts logic of the use case away from entity classes (that store persistent data) The roles of classes are defined according to their responsibilities in the use- case realization Robustness analysis generates class stereotypes 15 Boundary – Control – Entity Class stereotypes differentiate the roles objects can play: ❖ Boundary objects model interaction between the system and actors (and other systems) ❖ Control objects co-ordinate and control other objects ❖ Entity objects represent information and behaviour in the application domain ❖Boundary – Control – Entity architecture 16 Boundary – Control – Entity Within this architecture, objects can have various typical roles o boundary objects interact with outside actors o control objects manage use case behaviour o entity objects maintain data These are represented explicitly in UML by using analysis class stereotypes ❖Entity classes may be imported from domain model ❖ Boundary and control classes are more likely to be unique to one application 17 Boundary – Control – Entity Boundary classes represent interaction with the user - likely to be unique to the use case but inherited from a library We use stereotypes (label or icons) to indicate boundary classes Notations: CustomerUX CustomerUX CustomerUX 18 Boundary – Control – Entity Control classes encapsulate unique behaviour of a use case Specific logic kept separate from the common behaviour of entity classes As before, we use stereotypes (label or icons) to indicate entity classes Notations: Registration Registration Registration 19 Boundary – Control – Entity Entity classes represent persistent data and common behaviour likely to be used in more than one application system. As before, we use stereotypes (label or icons) to indicate entity classes Notations: Product Product Product 20 Boundary – Control – Entity: Example Let’s see again the example we used in previous weeks – just the very first part; we’ll keep it simple. ◦ Users browse through the site. They place items it in the shopping cart. In order to buy a product, they must register, create an account and become “customers”. Create a design class diagram Step 1: identify the obvious classes (class identification; see week 2 notes). Step 2: create the classes. Very important: when you create the class diagram at design level, It is mandatory to add all the attributes and behaviours as well as visibility Step 3: create the relationships 21 Boundary – Control – Entity: Example Users browse through the site. They place items it in the shopping cart. In order to buy a product, they must register, create an account and become “customers”. Step 4: Go through the description again; identify actions. Are there any classes that are NOT part of the problem domain but they are important for the design/implementation of the system? Consider: “register” and “browse” What kind of classes could we create out of them? ”Register” → Registration class “Browse” → Interface class 22 Boundary – Control – Entity: Example “Registration” class: what does it do? The user must register in order to create an account. If the user is not registered, then the user cannot have an account. “Registration” is a control class (Specific logic kept separate from the common behaviour of entity classes) “Browse” indicates interaction between the user and the system. “Interface” class is a boundary class 23 Boundary – Control – Entity: Example All the other classes (apart from boundary and control) are entity classes. Usually, we do not declare them but if we want to do it, we use the stereotype: or 24 BCE pattern By introducing the 3 different roles of classes, we introduce the “Boundary-Control-Entity” (BCE) architectural pattern. You can also find it with the abbreviations: EBC or ECB The BEC pattern organises the responsibilities of classes according to their role in the use-case realization. The BEC pattern assumes that the responsibilities of the classes is also reflected in the relations and interactions between the different categories of classes in order to ensure the robustness of the design. (https://en.wikipedia.org/wiki/Entity-control-boundary) The BEC pattern is similar to other patterns (Model-View-Contoller pattern) and it is compatible with other architectural design paradigms (e.g. clean architecture) We’ll discuss patterns in more details later in the module; for the time being, keep in mind that “Boundary-Control-Entity” (BCE) is an architectural pattern 25 Classes and classifiers A class diagram consists of: ❖ Classifiers ❖ Features ❖ Relationships Figure on the right: https://www.linkedin.com/learning/software-design- modeling-with-uml/class-diagrams-key- elements?autoplay=true&resume=false&u=42314660 26 Classes and classifiers Some classes might be similar to others in relation to the role they play (remember: boundary – control) or to certain attributes etc. That is why we introduce the term “classifier”. What is a classifier? A classifier describes a set of classes / instances that have common behavioral and- / or structural features. In UML diagrams, the term classifier is used to categorize a group of model elements that have similar structural features, which include attributes and associations, and similar behavioral features, which include operations and methods. Classifier is an abstract meta-class which describes (classifies) set of instances having common features. 27 Classes and classifiers When we start modelling every class starts as a “regular” class. At the beginning it is difficult to say if a “regular class” has any further role. This comes later, as you develop the model, and you start to see the potential of applying some design patterns and improve the quality of your design. 6 types of classifiers: Figure on the right: https://www.linkedin.com/learning/software- design-modeling-with-uml/class-diagrams-classifiers-and- features?autoplay=true&resume=false&u=42314660 28 Classes and classifiers As we said last week about classes, all classifiers have common notation (slightly different is the “active class”): A box with 3 compartments ◦ Top: Name (with stereotype or not) ◦ Properties or Attributes (structural features) ◦ Methods (behavioral features) 29 Classifiers: Abstract class Consider the following example: Class “animal” does not create object(s) directly. It inherits to sub-classes and object(s) are created from sub-classes. “Animal” is an abstract class. An abstract class exists ONLY for the other classes to inherite. 30 Classifiers: Abstract class An abstract class cannot be instantiated; it cannot be used to create objects. In order to access an abstract class and use it, it must be inherited from another (child) sub-class. The purpose of an abstract class is s to provide a common definition of a base class; multiple derived classes (subclasses) can share this common definition. The methods of an abstract class can be implemented by the subclasses only; they are called abstract methods. https://www.linkedin.com/learning/programming-foundations-object-oriented- design-3/abstract-and-concrete- classes?autoplay=true&resume=false&u=42314660 31 Classifiers: Interface “Interface” specifies a named set of operations Used to: Separate the specification of functionality from implementation of functionality The interface provides The plugs and sockets to connect from outside Interface is realized by any number of classes An interface cannot be instantiated – no object(s) can be generated 32 Classifiers: Interface Interface contains operations The operations of an interface should be fully specified A stereotype and/or set of constraints and/or tagged values can be used (optional) The followings are not allowed in interfaces o Operation implementations o Relationships An interface may have a generalization relationship to another interface this means that an interface can extend another interface by inheriting its operations 33 Classifiers: Interface Interfaces are not discovered from the analysis of the application domain They are discovered based on design considerations o fundamental for enforcing architectural frameworks o They can be used to break cyclic dependencies in the system o They can be used to hide the implementation from unauthorized clients; interface reveals only a limited portion of the behavior of an actual class Class that uses (requires) the interface can be indicated by a dashed arrow pointing to the interface ◦ the arrow can be stereotyped with the keyword «use» Class that implements (realizes) the interface is indicated by a dashed lined with a triangular end (the interface is implemented by class) ◦ the line can be stereotyped with the keyword «implement» 34 Classifiers: Interface Consider the example on the right. What does the arrow from “Tape Player” mean? What does the arrow from “Recorder” mean? https://www.linkedin.com/learning/programming-foundations-object- oriented-design- 3/interfaces?autoSkip=true&autoplay=true&resume=false&u=42314660 35 Classifiers: Interface Advantages of interfaces  increase flexibility and extensibility  a model can be neatly separated in cohesive subsystems  by using interfaces the number of dependencies between classes, subsystems and components are reduced Drawbacks of interfaces  relate to added complexity and increased performance costs As a guideline,  use interfaces for the more “fluid” parts of the system  dispense them for the more stable parts of the system 36 Classifiers: Abstract class vs Interface Abstract Class Interface Can contain fields and methods Contains only behaviour(s) Subclasses extend the behaviour Subclasses implement the of the abstract class behaviour of the interface Subclasses cannot inherit from Subclasses can implement multiple multiple abstract classes interfaces Can have different visibility All methods are public Both, are NOT instantiated. 37 Class diagram – design tips Tips for class diagram Before you start creating a class diagram, make sure you understand the model Position the classes, from the most relevant to the least relevant and from top to bottom and left to right. Make sure that there is no overlapping Make sure no line goes behind a class Avoid diagonal connectors; if possible, use straight lines / edges. 38 Object diagram The next diagram we’ll discuss is object diagram. Similarly to class diagram, object diagram is a structure diagram. Object diagram aims to model instances of the system It is a snapshot of the objects in a system And relationships that exist among those objects At specific point in time Objects are created at run-time as instances of classes Objects encapsulate their data 39 Object diagram Object Notation of object diagram Slot Object: The name of the object Relationship Slot: Values Relationships https://www.linkedin.com/learning/software-design-modeling-with- uml/object-diagram?autoplay=true&resume=false&u=42314660 40  Object diagram An object diagram derives from a class diagram. When we create an object diagram, we must always work according and in relation to the description given in the class diagram Object: name followed by “:” followed by the name of the classifier, underlined We can omit the name of the object and just have :clasiffier_name, underlined ➔ anonymous object Slots: values of class attributes; not necessarily all attributes, only those that are important for what we model. Slots do NOT include METHODS (structural) Class diagram Object diagram Relationships: the same as in class; same names, same notations 41 Object diagram Example from Udemy course “Master UML - A Complete Unified Modeling Language Guide”, instructor: Amit Chugh Can you identify the classes that participate in the class diagram 42 Class diagram vs Object diagram Class diagram Object diagram Static aspect of a system Behaviour of a system in real time No values of an instance Includes attributes and data values of an instance Behaviours No behaviours Represents abstract model consisting Represents an instance at a of classes and their behaviour particular moment which is concrete in nature Number of class diagrams are limited We could have unlimited number of instances – each one unique 43 Summary Today we covered the following topics: Class and design Boundary – Control – Entity classes BCE pattern Classifiers: Class, Abstract class, Interface Object diagram We have now completed the class diagram and the object diagram. 44 Next week Next week, we’ll discuss interaction diagrams: ◦ Sequence diagram ◦ Collaboration diagram VERY IMPORTANT: Coursework groups The coursework will be given out during the tutorial, today (week 3). 45