1. CS223: Software Engineering Lecture 9: System Modeling

2. Recap Phases in SRS formation Interviewing techniques Requirement change management

3. Objective After the end of the class students should be able to o Explain the purpose of modelling o Draw UML diagrams  Use-case diagram  Class Diagram

4. System modeling The process of developing abstract models of a system, with each model presenting a different view or perspective of that system. Means of representing a system using some kind of graphical notation (UML). System modelling helps the analyst to understand the functionality of the system These models are used to communicate with customers.

5. Why do we need models? Solutions Method: Real Systems may not be available, accessible, affordable … o Represent the System as a Model o Solve problems on the Model o Map the solutions back to the System Human Cognition Mechanism is limited o Short Term & Long Term Memory o Ability to track only up to 7 entities Models are Abstractions that help track complexity

6. Models we may have seen … Physics o Time-Distance Equation Chemistry o Valency-Bond Structures Mathematics o All about models … Geography o Maps o Projections Electrical Circuits o Kirchoff’s Loop Equations o Time Series Signals & FFT o Transistor Models Building & Bridges o Drawings o Finite Element Models Machine Design o Differential Equations

7. The Model as an Abstraction of the Reality We are not able to comprehend a complex system in its entirety - a single model is not enough ◦ different perspectives are required, which in turn require different models being independent from each other ◦ each model must exist on different levels of granularity Good models are necessary... ◦ for making complex systems more understandable ◦ for visualizing the essential aspects of a system ◦ for communication among project members and with the customer ◦ for ensuring architectural soundness

8. Abstraction Several abstractions of the same problem possible: o Focus on some specific aspect and ignore the rest. o Different types of models help understand different aspects of the problem.

9. Abstraction A map is: An abstract representation.

10. Abstraction For complex problems: o A single level of abstraction is inadequate. o A hierarchy of abstractions needs to be constructed. Hierarchy of models: o A model in one layer is an abstraction of the lower layer model. o An implementation of the model at the higher layer.

11. Hierarchical Abstraction Example Suppose you are asked to understand the life forms that inhabit the earth. If you start examining each living organism: o You will almost never complete it. o Also, get thoroughly confused. You can build an abstraction hierarchy.

12. Living Organisms AnimaliaFungaePlantae Kingdom Mollusca Chordata Ascomycota Zygomycota Homo SapienSolanum Tuberosum Coprinus Comatus Phyllum Species

13. The Model as an Abstraction of the Reality We are not able to comprehend a complex system in its entirety - a single model is not enough  different perspectives are required, which in turn require different models being independent from each other  each model must exist on different levels of granularity Good models are necessary...  for making complex systems more understandable  for visualizing the essential aspects of a system  for communication among project members and with the customer  for ensuring architectural soundness

14. What is the UML? Goals Provide users with an expressive modeling language ◦ for the specification, construction, visualization and documentation of the artifacts of a software system ◦ for the construction of different kinds of models ◦ for the exchange of models Provide users with ready-to-use core concepts ◦ however, extensibility and specialization mechanisms are available

15. UML Goals Provide a formal basis for understanding the modeling language ◦ Meta-model in terms of a UML class diagram ◦ “Semantics” is part of the official UML documentation Support higher-level development concepts ◦ such as collaborations, patterns, and components Integrate best practices

16. What is the UML not? It is the explicit intention of the UML developers not to prescribe ◦ a certain process ◦ a certain modeling tool ◦ any modeling guidelines ◦ a certain programming language Dedicated Goal: Openness!

17. Objects – Core to S/W Models Defines object-orientation Has multiple viewpoints o Modeling / Conceptual o Philosophical o Software Engineering o Implementation o Formal Fundamental and most widely used UML model

18. Objects – Number Example Complex Numbers o Variables  Real Part  Imaginary Part o Operations  Create  Norm  Add / Subtract

19. Objects – Geometry Examples Points o Variables  X Coordinate  Y Coordinate o Operations  GetX / SetX  GetY / SetY  FindQuadrant Lines o Variables  Point 1  Point 2 o Operations  GetPt1 / SetPt1  GetPt2 / SetPt2  FindLength

20. Objects – Geometry Examples Triangles o Variables  Point 1  Point 2  Point 3 o Operations  GetPt1 / SetPt1  GetPt2 / SetPt2  GetPt3 / SetPt3  FindPerimeter  FindArea Polygon o Variables  Number of Points  Array of Points o Operations  GetPtCount  GetPt(int i)  FindPerimeter  FindArea

21. Objects – Library Example 1 Books o Variables  Acc_no  Title  Author  Publisher  Status // Issued, Available  Borrower // Member o Operations  Get  Acc_no, Title, Author, Publisher, Status  Issue(Member)  Return Members o Variables  Member_ID  Name  Address  Books_Issued // Array of Books o Operations  Get  Member_ID, Name, Address, Books_Issued, FreeCards

22. Objects – Library Example 2 Books o Variables  Acc_no, Title, Author, Publisher, Status o Operations: Get Members o Variables  Member_ID, Name, Address, Count of Books_Issued o Operations: Get Borrow_Register o Variables  Borrow_ID  Acc_no  Member_ID  Borrow_Date  Operator_ID o Operations  Borrow(Books, Members)  Return(Books)

23. Relations between Objects RelationExample Specialization- Generalization, IS-A Book is-a Publication Journal is-a Periodical Periodical is-a Publication Whole-Part, HAS-ABook has-a Title Book has-a Publisher Publisher has-a Address Member-of, HASLibrary has Member

24. Relations between Objects IS-A o Class or Type Hierarchy HAS-A o Composition  Uniquely contains the component o Aggregation (called ‘Weak’ Aggregation)  Multiple containments possible Member-of o Special case of HAS-A o Does not support transitivity

25. Diagrams of UML (1) Use Case Diagram (2) Class Diagram (3) Sequence Diagram (4) Collaboration Diagram (5) Statechart Diagram (6) Activity Diagram (7) Component Diagram (8) Deployment Diagram Implementation Diagrams Interaction Diagrams Behavior Diagrams

26. Use case modeling Use cases were developed originally to support requirements elicitation and now incorporated into the UML. Each use case represents a discrete task that involves external interaction with a system. Actors in a use case may be people or other systems. Represented diagramatically to provide an overview of the use case and in a more detailed textual form.

27. Use case diagram What is being described? (The system.) Who interacts with the system? (The actors.) What can the actors do? (The use cases.)

28. Use Cases A use case describes functionality expected from the system to be developed a use case is triggered either by invocation of an actor or by a trigger event, in short, a trigger A use case is usually represented as an ellipse.

29. System The set of all use cases together describes the functionality that a software system provides Query student data Issue certificate Announce Exam Student Administration system

30. Actors It is essential to document who actually works and interacts with the system Actors always interact with the system in the context of their use cases Actors are represented by stick figures

31. Example

32. Relationships between Actors Actors often have common properties and some use cases can be used by various actors

33. Relationships between Use Cases «include» relationships o Use cases that are included as parts of other use cases. o Enable to factor common behavior. «extend» relationships o Use cases that extend the behavior of other core use cases. o Enable to factor variants. Generalizations of use cases o Use cases that are specialized versions of other use cases

34. Example Base use case Included use case Extending use case Base use case

35. Condition

36. Class diagrams They are used when developing an object-oriented system model o To show the classes in a system and the associations between these classes. An object class can be thought of as a general definition of one kind of system object. An association is a link between classes that indicates that there is some relationship between these classes. Objects represent something in the real world o e.g. a patient, a prescription, doctor, etc.

37. Essential features Class Attributes Operations Relationships o Associations o Generalization o Realization Dependency Constraint Rules and Notes

38. Class Describes a set of objects having similar: o Attributes (status) o Operations (behavior) o Relationships with other classes Attributes and operations may o have their visibility marked: o "+" for public o "#" for protected o "−" for private o "~" for package

39. Example Class Name Attributes Operations

40. Associations: Example StaffMemberStudent 1..**instructs instructor Association name Role name Multiplicity Navigable (uni-directional) association Courses pre - requisites 0..3 Reflexive association Role *

41. Aggregation A special form of association that models a whole-part relationship between an aggregate (the whole) and its parts. o Models a “is a part-part of” relationship. Whole Part Car Door House 1..*2..*

42. Composition A strong form of aggregation o The whole is the sole owner of its part.  The part object may belong to only one whole o Multiplicity on the whole side must be zero or one. o The life time of the part is dependent upon the whole.  The composite must manage the creation and destruction of its parts. CirclePoint 3..* 1 Polygon Point Circle

43. Generalization Indicates that objects of the specialized class (subclass) are substitutable for objects of the generalized class (super-class). o “is kind of” relationship. Shape {abstract} Circle Super Class Sub Class An abstract class Generalization relationship {abstract} is a tagged value that indicates that the class is abstract. The name of an abstract class should be italicized

44. Thank you Next Lecture: System Modeling