









Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Finding Analysis Classes, Analysis Workflow, Analyze a Use Case, Good Analysis Classes, Bad Analysis Classes, Class Identification Techniques, Noun analysis, Verb analysis, Grammatical Parsing, CRC Analysis, CRC Cards, CRC Analysis Procedure, Use-Case-Based Analysis, Real-World Analysis, Analysis Model, Raman Ramsin, Lecture Slides, Object Oriented Design, Department of Computer Engineering, Sharif University of Technology, Iran.
Typology: Slides
1 / 15
This page cannot be seen from the preview
Don't miss anything!










Department of Computer Engineering
Department of Computer Engineering
Analysis Workflow: Analyze a Use Case The analysis workflow consists of the following activities: Architectural analysis Analyze a use case Outputs: analysis classes use case realizations Analyze a class Analyze a package
Department of Computer Engineering
Good Analysis Classes What makes a good analysis class? Its name reflects its intent. It is a crisp abstraction that models one specific element of the problem domain. It maps to a clearly identifiable feature of the problem domain. It has a small, well-defined set of responsibilities: a responsibility is a contract or obligation that a class has to its clients; a responsibility is a semantically cohesive set of operations; there should only be about three to five responsibilities per class. It has high cohesion - all features of the class should help to realize its intent. It has low coupling - a class should only collaborate with a small number of other classes to realize its intent.
Department of Computer Engineering
Bad Analysis Classes What makes a bad analysis class? A functoid - a class with only one operation. A stand-alone class - each class should be associated with a small number of other classes with which it collaborates to deliver the desired benefit. An omnipotent class - a class that does everything (classes with "system" or "controller" in their name may need closer scrutiny). A class with a deep inheritance tree - in the real world inheritance trees tend to be shallow. A class with low cohesion. A class with high coupling. Many very small classes in a model – merging should be considered. Few but large classes in a model – decomposition should be considered.
Department of Computer Engineering
Noun/verb analysis ( Grammatical Parsing)
Department of Computer Engineering
CRC Analysis – CRC Cards CRC – Class, Responsibilities, and Collaborators Important things in the problem domain are written on CRC Cards. Each Card has three compartments: class - contains the name of the class responsibilities - contains a list of the responsibilities of that class (the functions it performs and even the information it is responsible to keep and provide) collaborators - contains a list of other classes with which this class collaborates in order to fulfill the responsibilities
Department of Computer Engineering
CRC Analysis Procedure – Phase 2 The participants are 00 analysts and domain experts. Phase 2 : Decide which sticky notes should become classes and which should become attributes: Analysis classes must represent a crisp abstraction in the problem domain. Certain sticky notes will represent key business concepts and clearly need to become classes. If a note logically seems to be a part of another note, this is a good indication that it represents an attribute. If a note doesn't seem to be particularly important or has very little interesting behavior, see if it can be made an attribute of another class. If in doubt about a note, just make it a class.
Department of Computer Engineering
Use-Case-Based Analysis Complements other techniques Starts from an initial list of classes List of classes is perfected and refined based on use cases: Behavioral models are built showing use case realizations Classes are identified based on the objects needed for use case realizations: the list of classes should provide instances which implement the behavior needed for the use cases;
Department of Computer Engineering
Real-World Analysis Explore the real world for classes: Candidates: physical objects, paperwork, interfaces to the outside world, and conceptual entities; Physical objects: Things such as aircraft, people, and hotels may all indicate classes. Paperwork: Things like invoices, orders, and bankbooks may all indicate possible classes; beware of paperwork supporting the redundant business processes that the new system might be trying to replace. Known interfaces to the outside world: Things such as screens, keyboards, peripherals, and other systems can be a source of candidate classes, especially for embedded systems. Conceptual entities: Things that are crucial to the operation of the business but are not manifest as concrete things; such as enrollment, educational program, and alarm condition.
Department of Computer Engineering
Analysis Model Create a first-cut analysis model: compare noun/verb analysis results with CRC results and the results of an examination of other sources of classes. resolve synonyms and homonyms. differences between the results of the different techniques indicate areas of uncertainty. consolidate results into a first-cut analysis model.