Object Oriented Software Engineering   View all facts   Glossary   Help

subject > person or group > person > stakeholder > software developer > designer > UML diagram designer

UML diagram designer
subject			fact

UML diagram designer	can find classes by extracting the nouns and noun phrases from source materials
	can hide part objects inside the aggregate object to improve the encapsulation of the system so that methods in the system would be able to perform most operations on the aggregate, without needing to know about the existence of the parts
	can identify generalizations using a bottom-up approach to identifying generalizations or a top-down approach to identifying generalizations
	discovers classes in source material such as requirements descriptions, interview notes, or the results of brainstorming sessions
	identifies associations and attributes once a good initial list of classes has been identified, starting with the most important classes and working outwards towards the classes that are less important
	invents classes that are needed to solve a particular design problem
	is a subtopic of 5.2 - Essentials of UML Class Diagrams
	is a kind of designer
	should ask herself whether a less restrictive multiplicity could also makes sense in some circumstances
	should avoid overdoing generalization
	should be concerned with reuse when identifying classes
	should create an interface instead of a superclass if you will sometimes need to declare a variable that can contain instances of several classes, yet: The classes are very dissimilar except for having a few operations in common, or One or more of the classes already have their own superclasses, or Different implementations of the same class might be available
	should create a distinct class if a subset of a class's attributes form a coherent group
	should defer decisions about directionality to later phases of development, when the detailed design is created because although making associations one-directional can improve efficiency and reduce complexity, it might also limit the flexibility of the system.
	should distribute responsibilities among the classes so no one class has an unfair share, and hence becomes unduly complex
	should mark an association as an aggregation if the following are true: You can state that the parts 'are part of' the aggregate, or the aggregate 'is composed of' the parts When something owns or controls the aggregate, then they also own or control the parts
	should not represent actions as if they were associations
	should not think of generalizations as special associations, a common misconception which arises because both generalizations and associations connect classes together in a class diagram
	should read every association in both directions to verify that it makes sense because it is very common to make errors when creating associations - it is particularly easy to get the multiplicity wrong
	should split a class into several distinct classes if it has too many responsibilities
	should work in the following sequence Identify a first set of candidate classes Starting with the most important classes, add any associations and attributes that clearly will be needed Work out the most clear generalizations List the main responsibilities of each class Based on responsibilities, decide on specific operations that are needed Iterate over the entire process, examining the model to see if you need to add or delete classes, associations, attributes, generalizations, responsibilities or operations Repeat the last step as needed until the model is satisfactory
designer	can learn from studying patterns
	can use cost-benefit analysis to choose among alternatives
	makes design decision
	may also be a programmer
	should not design large systems until she has experienced a wide variety of software development projects
	should study designs of other systems, including designs that have been found to be bad
software developer	asks several evaluators to independently perform heuristic evaluations
	develops software
	has goal rewarding career, recognition, or the challenge of solving difficult problems or by being a well-respected 'guru' in a certain area of expertise
	is part of software development team
	maintains software
	may be judged on when they deliver product, not on its quality level
	may be reluctant to develop new libraries, APIs and frameworks because developing anything reusable is seen as not directly benefiting the current customer If a developer has painstakingly developed a high-quality reusable component, but management only rewards the efforts of people who create the more visible 'final product', then that developer will be reluctant to spend time on reusable components in the future Efforts at creating reusable software are often done in a hurry and without enough attention to quality. People thus lose confidence in the resulting components, and in the concepts of reuse and reusability
	may refuse to reuse components in which they lack confidence
	most often works on custom software
	must ensure that the set of use cases is complete and that they are expressed consistently and unambiguously
	must inform the project manager about any problems
	must understand the customer's business environment, their problems and the available technology which can be used to solve the problems
	often fails to adequately involve users in the development process
	often has significantly less knowledge about modelling than about design and programming
	often underestimates software development time because it is very hard for people to assess the quality of software or to appreciate the amount of work involved in its development
	performs cost estimation
	reuses libraries and APIs delivered with a programming language
	should be rewarded for developing reusable components
	should emphasize the use case or use cases which are central to the system, which represent a high risk because of problematic implementation, or which have high political or commercial value
	should not document a design only after it is complete
	should not omit design documentation
	should only reuse technology that others are also reusing
	should realize that attention to quality of reusable components is essential so that potential re-users have confidence in them
	should realize that developing and reusing reusable components improves reliability, and can foster a sense of confidence
	should realize that developing reusable components will normally simplify the resulting design, independently of whether reuse actually occurs
	should work for several months on a testing team; this will heighten her awareness of quality problems she should avoid when she returns to designing software
	wants software that is easy to design and maintain and which has parts that are easy to reuse
stakeholder	must agree on requirements

Next designer: user interface designer    Up: designer    Previous designer: software designer