Analysis Modeling (cont’d) CpSc 372: Introduction to Software Engineering Jason O. Hallstrom Authorship Disclaimer. These slides are intended to serve as teaching instruments for an undergraduate course in Software Engineering. While the slides were formatted by Dr. Hallstrom, the content is compiled from other sources, including the readings listed on the course website, Dr. Pressman’s Software Engineering textbook, and various internet materials. In almost every case, the ideas belong to someone other than Dr. Hallstrom. Indeed, text is often quoted verbatim without an explicit citation (to improve the readability of the slides). The original authors retain all copyrights. If you are interested in citing any of the material in these slides, please contact Dr. Hallstrom for the original source(s). DO NOT CITE THIS PRESENTATION. THE CONTENT SHOULD NOT BE ATTRIBUTED TO DR. HALLSTROM. SEE DR. HALLSTROM IF YOU HAVE ANY QUESTIONS.

CpSc 372 A Roadmap Use-cases Use-case diagrams Activity diagrams Swimlane diagrams Data object diagrams ERD diagrams Data flow diagrams Process specifications We are going to examine some of the key tools used for creating an analysis model. General Structured AnalysisOO Analysis Class diagrams Packages CRC cards Sequence Diagrams These tools are not specific to either structured analysis or OO analysis.

CpSc 372 A Different View Models analysis classes  Data  Processes Models class collaborations Object-Oriented Analysis Class diagrams Packages CRC cards Sequence diagrams modeled using Modeling Tools: modeled using Object-oriented analysis results in an analysis model that describes a system of collaborating objects. Every object encapsulates a set of data elements, and exports a set of operations for working with those elements.

CpSc 372 What is a Class? Each class is like a template that defines how instances of the class – objects – should be created. A class consists of a set of attributes and methods. A class diagram is used to show the static structure of a class. AnsweringMachine -greeting -messages +setGreeting() +getMessages() +recordMessage() AnsweringMachine -greeting -messages +setGreeting() +getMessages() +recordMessage() classes objects Class name Attributes Methods

CpSc 372 Accessibility Attributes and methods can be declared at three levels of visibility. Public (+)  Visible everywhere Private (-)  Visible only from within the declaring class Protected (#)  Visible only from within the declaring class and any of its subclasses We will all now swear never to declare public attributes. class diagram notation

CpSc 372 Inheritance Inheritance allows a subclass to inherit the attributes and methods of a superclass. AnsweringMachine -greeting -messages +setGreeting() +getMessages() +recordMessage() AnsweringMachine -greeting -messages +setGreeting() +getMessages() +recordMessage() AnsweringMachineWithTime -time +setTime() AnsweringMachineWithTime -time +setTime() “inherits from” or “specializes” A subclass begins with everything provided by its superclass (or base class). Can add additional attributes and methods Can override existing public/protected methods

CpSc 372 Inheritance Hierarchy An inheritance hierarchy (or class hierarchy) refers to all of the classes in a system, and the inheritance relations among them. Depending on the type of system being developed, the class hierarchy can be complex! /library/en-us/cpref/html/frlrfsystemhierarchy.asp

CpSc 372 Associations Just like data objects, classes can be related to one another. These relationships are called “associations”. AnsweringMachine -greeting -messages +setGreeting() +getMessages() +recordMessage() AnsweringMachine -greeting -messages +setGreeting() +getMessages() +recordMessage() 1 1 callHandler multiplicity directionname Telephone -phoneNumber +getPhoneNumber() +dialPhone() +answerPhone() Telephone -phoneNumber +getPhoneNumber() +dialPhone() +answerPhone()

CpSc 372 Other Associations Whole PartA PartB Composition Aggregation Defines a whole/part relationship. “…” + with lifetime guarantees. Multiplicity may be specified in either case. Whole PartA PartB

CpSc 372 Identifying Analysis Classes Just like in structured analysis, we begin with a grammatical parse. Nouns  Candidate classes External entities, events, places, structures, things, etc.  Candidate attributes Entities that naturally belong to a class Verbs  Candidate methods Operations that manipulate data Operations that perform a computation Operations that inquire about state Operations that check for a control event

CpSc 372 Building the OOA Model Identify class responsibilities  What are its primary jobs? Identify class relationships and collaborations  What other classes does it need to interact with?  How will they interact? Identify class commonalities and variabilities  Which attributes/methods do they have in common?  Which attributes/methods vary? Use the initial set of analysis classes as the basis for building the OOA model. This will be an iterative process!

CpSc 372 Some Rules of Thumb Focus on the problem  Identify “what” classes/attributes  Ignore “how” classes/attributes Focus on core classes  Eliminate procedural classes  Avoid data classes  Avoid classes with only a single attribute Use (don’t overuse) inheritance  Move commonalities up the hierarchy  Move variabilities down the hierarchy  Avoid deep hierarchies

CpSc 372 Distribution, Cohesion, and Encapsulation Responsibility distribution  Intelligence should be distributed across classes  Avoid monolithic classes Class cohesion  Classes should be single minded  Avoid classes with unrelated members Encapsulation  The class with the data should do the work  Avoid passing state to other classes Some additional model desiderata: This is beginning to look like design work!