PB007 Software Engineering I — Analytical Class Diagram1 Analytical Class Diagram PB007 Software Engineering I Lukáš Daubner daubner@mail.muni.cz PB007 Software Engineering I — Analytical Class Diagram2 In general Class Diagram ̶ Static view ̶ Modelling of: ̶ Classes ̶ Attributes ̶ Operations ̶ Relationships PB007 Software Engineering I — Analytical Class Diagram3 Analytical Class Diagram ̶ Depicts concepts, abstractions, not pieces of code ̶ Relationships ̶ Attributes ̶ It helps us to grasp the domain, make a sense of it ̶ Specify terminology, relationships, dependances, … ̶ ADVANCED: Patterns (Analysis Patterns) ̶ Reusable models – solution to a concrete repeating problems ̶ See this book: Martin Fowler: Analysis Patterns - Reusable Object Models PB007 Software Engineering I — Analytical Class Diagram4 Analytical Class Diagram ̶ Do not delve into implementation details. Forget about programming ̶ Types ̶ Constructors ̶ Boilerplate methods and classes ̶ Properties (getters, setters) ̶ Language-specific constructs ̶ Etc. PB007 Software Engineering I — Analytical Class Diagram5 How should it look like? Analytical Class Diagram ̶ Representative name ̶ Small number of responsibilities (operations) ̶ ~3-5 ̶ It is not isolated – A part of a system ̶ Low coupling – No spaghetti classes ̶ High cohesion ̶ Operations have MUCH in common ̶ Zeppelin class has operations related to its operation: CheckAvailability() CheckMaintenacePeriod() Discontinue() Register() PB007 Software Engineering I — Analytical Class Diagram6 Do’s and Dont’s Analytical Class Diagram ̶ Lots of small classes ̶ Few big classes ̶ Service/managers/builders/boilerplate classes ̶ Implementational details, not important for the concept ̶ Try not to think so much about how would you code it ̶ We are not there yet ̶ Complex inheritance hierarchy ̶ Functoids ̶ Classes representing a function or procedure ̶ No interfaces ̶ Again, implementational details PB007 Software Engineering I — Analytical Class Diagram7 Analytical Class Diagram – Example PB007 Software Engineering I — Analytical Class Diagram8 For example… How to find analytical classes ̶ Textual analysis ̶ Use specification, use cases, or any other material available to you ̶ Nouns (Podstaná jména) are often classes or attributes ̶ Verbs (Slovesa) are often relationships or operations ̶ Watch out for “hidden” classes – only implied in the text ̶ Brainstorming ̶ Records candidate classes on sticky notes ̶ Write down their responsibilities ̶ Search for collaborations between them PB007 Software Engineering I — Analytical Class Diagram9 Relationships between classes ̶ Association ̶ Semantic relationship – from domain ̶ It implies an attribute in one (or both) of the classes – usually ̶ Long-term relationship ̶ It contains: Name, or name or roles Multiplicity Navigability ̶ Multiplicity ̶ How many “partners” can the class have (1:1, 1:N, M:N) ̶ Navigability ̶ Can we effectively “get” from one class to another PB007 Software Engineering I — Analytical Class Diagram10 Relationships between classes ̶ Association M:N ̶ All fine in analytical class diagram, it is decomposed later in design class diagram ̶ But, if the relationship is complex, you need to decompose it now ̶ Or use association class, there is at most one relationship between two instances These two diagrams are not equivalent Person p can have multiple Jobs in a Company c Person p can have only one Job in a Company c PB007 Software Engineering I — Analytical Class Diagram11 Relationships between classes ̶ Multiple associations ̶ Different relationships ̶ Reflexive association PB007 Software Engineering I — Analytical Class Diagram12 Relationships between classes ̶ Dependency ̶ „Weak association“ ̶ Represents a relationship where a change on one class might affect the other ̶ One class somehow depends on the other ̶ The exact meaning is specified by stereotypes ̶ The most common is «use», meaning that some operation uses the other object as attribute or return value. But it does not have it as attribute. PB007 Software Engineering I — Analytical Class Diagram13 You gotta do what you gotta do Task for this week ̶ Process the feedback ̶ Using the specification and Use Case Diagram, identify analytical classes, their attributes, association, and operations ̶ Don’t forget inheritance and multiplicity ̶ BONUS: Navigability ̶ You will have to do it someday PB007 Software Engineering I — Analytical Class Diagram14 You gotta do what you gotta do Task for next week ̶ Process the feedback ̶ Update the Use Case Diagram. They must describe the same system. ̶ Consider the interaction between objects when fulfilling use cases. Are they represented by your Analytical Class Diagram? ̶ Do your part in peer review ̶ Link to roster is in study materials