Object-oriented analysis and design

from Wikipedia, the free encyclopedia

Object-oriented analysis and design ( OOAD ) are object-oriented variants of the two general activities requirements analysis (object-oriented analysis) and system design (object-oriented design) in the development process of a software system .

The fact that object-oriented techniques are already used in the development phases of analysis and design facilitates the transition to implementation in an object-oriented programming language .

The Unified Modeling Language (UML for short) has established itself as the standard notation for object-oriented models . A process model that was specially developed for object-oriented techniques and UML is the so-called Rational Unified Process (RUP).

The analysis is about recording and describing the requirements that the software system to be developed should meet. In this phase all facts are collected, presented and checked. This can be done in the form of a textual specification sheet or a software requirements specification . The result of the analysis is a general product model in the form of an object-oriented analysis model (OOA model). This technical description with object-oriented concepts contains various artifacts such as diagrams and representations of control structures .

With object-oriented design, the domain model created in the analysis is further developed and a system design is created based on this. The general model is transformed into a specific software architecture that contains information about details of the technical implementation and directly serves as a template for implementation in a programming language that ideally supports object-oriented programming (OOP).

Process models for software development

The main task of the project organization is to define a suitable development process for a specific software project and to implement it accordingly. A process model for software development is used to make it clear and manageable in terms of complexity. With all procedural models, in addition to the delimitation and coordination of the individual project phases, the conversion of a preliminary concept into an executable software product is important .

The waterfall model

Process models thus split individual activities into different phases in the development process. These are then - u. U. with minor modifications - run once (e.g. waterfall model ) or several times (e.g. spiral model ). If it is run several times, the individual software components are refined iteratively (i.e. repeatedly). There is disagreement about the optimal procedural models. As a rule, they differentiate between at least two large groups of activities in the development process: the analysis of business processes ( business process model and data model) (independent of the programming implementation ) on the one hand, and IT implementation (design and programming ) on the other.

Since the early 1980s, the importance and number of object-oriented analysis and design methods have been increasing steadily. In these, the results of the phases analysis, design and implementation are created in an object-oriented manner. Object-oriented programming languages are used for the latter . The fact that the same techniques are used in all these phases improves the consistency of the object-oriented techniques. In fact, the same notation is used in analysis and design. In the transition from object-oriented analysis to object-oriented design, no structural break occurs. One of the first approaches to modeling system requirements was "Object-Oriented Analysis" (OOA) by Peter Coad and Edward Yourdon . "Object-Oriented Design" (OOD) follows directly on from this and deals with the transition to design.

The Unified Modeling Language (UML for short), which was developed in the 1990s by Grady Booch , Ivar Jacobson and James Rumbaugh , has established itself as the standard notation for object-oriented models . The models in UML are the essential means of communication between developers and other participants in the software development process.

Static and dynamic aspects of the Rational Unified Process . The area under the curves shows the scope of the respective activities in the respective disciplines.

A process model that was specially developed for object-oriented techniques and UML is the so-called Rational Unified Process (RUP). It is a commercial product from Rational Software , which has been part of the IBM group since 2004 . The three programmers Grady Booch, Ivar Jacobson and James Rumbaugh were in charge of the development. The RUP defines the following disciplines:

  • Business modeling: An understanding of the business processes is achieved.
  • Requirements analysis (requirements): The requirements are recorded, documented and organized.
  • Analysis and design: The professional architecture is converted into a technical design.
  • Implementation: An executable software system is created.
  • Test: The software system is tested.
  • Deployment: The software system is delivered to the customer.

One advantage of the RUP is the iterative approach, which, in contrast to linear process models (such as the waterfall model), can also take changing requirements into account at a later point in time.

The object-oriented approach

The underlying idea of object orientation is to combine state (data) with behavior (functions on this data). The program sequence should be understood as an interplay of objects and their interactions. The objects are modeled based on the real world, in which objects and their interactions are an essential part. This is supplemented by the concept of the class , in which objects are grouped based on similar properties. You can think of classes as abstract templates for things with common properties and behaviors. An object is defined in the program code as an instance or incarnation of a class.

The core of every object-oriented consideration is the object. This is an instance of a certain data type or a certain class and is generated (instantiated) during runtime . Objects now contain attributes and methods. Attributes are only variables and constants that can accept values ​​and thus describe the "static nature" of the object. In contrast to this, there are “methods” that characterize the entire “dynamic behavior” of the object or a class; they contain the “algorithmic essence” of the object.

Example: The class carfor a car defines two attributes fuel(gasoline) and maxSpeed(top speed). These describe the condition of a car. Methods such as refuel()(refueling) or drive()(driving) can change the condition of a car. They thereby characterize the dynamic behavior. However, the class is caronly the (software) "blueprint" of a car. In order to deal with “concrete” cars during runtime, instances of this class must be created, for example objects polo, miniand beetle. A class is therefore sometimes compared to a cookie cutter, which is used to make many individual cookies.

A classification is generally a restriction / simplification of the real world in a very special context. So there will never be "the" classification. It always depends on the goal that is to be achieved with the classification. For example, while a class “car” in the context of a car manufacturer may have attributes such as wheels and color and will know its components (in the form of attributes or relationships), a class “car” in the context of a dealer has attributes such as product number, price, consumption and date of first registration. In the context of a registration office, there will be attributes such as license plate number, maximum permissible weight and the holder.

Grady Booch et al. name three important aspects that define object-oriented programming:

  • Object-oriented programs use objects (and not algorithms ) as fundamental logical building blocks.
  • Each object is an instance of a class.
  • Classes can be linked to other classes through the concept of inheritance .

Object-oriented analysis

The aim of the analysis is to determine and describe the customer's requirements for a new software system. In this phase, all aspects of the implementation are usually excluded. For example, the design of a user interface (e.g. GUI design) can already be carried out in the analysis, as this is the only way for many users to get a picture of the future application.

Object-oriented analysis is based on objects that are in the real world. These are not only objects, but also events and terms from the scope. The problem to be realized should be understood and described in an OOA model. This model should describe the essential structure and semantics of the problem, but not yet a technical solution. One also speaks of a technical concept , which consists of a static and a dynamic model:

  • The static model particularly shows the classes of the system, the relationships between the classes and the inheritance structures. Packages are used to gain a better overview of large systems.
  • The dynamic model describes the functional processes. Use cases describe the tasks performed at a high level of abstraction. These can be refined with activity diagrams or state diagrams. The OOA model must contain all the information in order to derive a prototype of the user interface from it.

Requirements engineering

The aim of requirements engineering (i.e. requirements elicitation) is to determine, specify, analyze, and validate the requirements for a new software product and then to derive a technical solution or to develop a product model. Object-oriented methods of requirements engineering generalize the concepts of object orientation, provide graphic notations for this and embed the concepts in a methodical framework. They lead to an integrated model of the functional requirements in which all relevant system aspects are taken into account. However, non-functional requirements can only be recorded in text form or through individual expansion.

conditions

Requirements determine what one expects from a software system. If there is a specific client, this will determine the most important requirements. If a product is developed for the anonymous market, then the marketing department and sales will determine the essential requirements. All persons and organizations who have an interest in software development or who are affected by the use of the software system are referred to using the English term stakeholder (dt. I. E. Partner, actor, interest representative).

The IEEE Standard 830 ( Software Requirements Specification ) differentiates between functional requirements and non-functional requirements. A functional requirement defines a function or service to be provided by the software system or one of its components. Functional requirements can be divided into

  • Requirements that describe the statics of the system,
  • Requirements that describe the dynamics of the system and
  • Requirements that describe the logic of the system.

Non-functional requirements, also called technical requirements or "Quality of Service" (QoS for short), mean aspects such as reliability , availability , concurrency , consumability , internationalization , information security , service requirements and support . Non-functional requirements have a major impact on the software architecture. They can also conflict with one another: for example, security often contradicts usability, and storage efficiency is usually the opposite of runtime efficiency.

Based on IEEE 830, Balzert lists a number of criteria that each individual requirement should meet:

  • Correct : The requirement is correct if the software system to be created fulfills it.
  • Unambiguous : The requirement is interpreted in the same way by all stakeholders.
  • Complete : The requirement must fully describe the required functionality.
  • Consistent : The requirement must be free of contradictions.
  • Classifiable according to importance (ranked for importance): The requirement can be assigned a level of importance. Some requirements can be essential, e.g. B. in life-critical applications, while others are only desirable. Possible classes are: "Essential", "Conditional" or "Optional" (optional).
  • Classifiable according to stability (ranked for stability): In this context, stability is understood to mean the number of expected changes in a request.
  • Verifiable : The requirement must be described in such a way that it can be verified or tested after implementation.
  • Traceable (traceable): The request must clearly be identified, eg. B. through a unique request number that remains unchanged.

The task of the requirements engineer is to work with the stakeholders to achieve these quality criteria for requirements as well as possible. In practice, however, one is often far from achieving this: "This problem arises from the fact that the interlocutors do not have a complete model of the system to be developed 'in their heads'."

Specifications and specifications

According to DIN 69901 , a requirement specification is a “set of requirements for the deliveries and services of a contractor determined by the client within a (project) order”. The specification sheet is therefore the basis for finding a solution in the course of the project. The main objectives are:

  • The description of the initial situation for the project (actual situation, goal and purpose, scope, etc.),
  • the description of the requirements for the project to be implemented,
  • ensuring that important topics are not forgotten,
  • the clear demarcation to the scope of the project to be created and
  • the agreement on the type and scope of the project task with regard to the ideas of the client and the contractor.

According to DIN 69901, a specification contains "implementation specifications drawn up by the contractor on the basis of the specifications specified by the client". From the point of view of the contractor, the specification sheet represents the formal and detailed answer to the client's requirements that were previously described in the specification sheet. The results to be provided by the contractor are thereby converted into necessary activities (obligations).

The requirement specification and requirement specification should enable the system analyst to create the OOA model. However, they have a lower level of detail than the OOA model.

Structural modeling

Structure diagrams are used to model the internal structure of a system. The two main types of diagram in object-oriented design are class diagrams and object diagrams . In order to model objects, it is investigated what reality looks like or how it can be represented in a simplified manner. All participating classes and their relationships are shown in a class diagram. In an object diagram, on the other hand, objects in the class diagram are shown at a specific point in time during execution.

Class diagram

Representation of a class

In UML notation , classes are specified as three-part rectangles, the components of which are the class name, a list of all attributes and a list of all operations and properties. These three categories are each separated by a horizontal line. If the class has no properties or operations, the bottom horizontal line can be omitted. Class names start with an uppercase letter and are singular nouns. Attributes are noted at least with their name and can also contain information on their type (i.e. class), an initial value, property values ​​and assertions. Operations are also listed at least with their name and can also contain information on possible parameters and their class, initial values ​​and any property values ​​and assurances. An operation means the abstract definition of a functionality - in contrast to the method, the concrete implementation of an operation.

Representation of an association

An association models connections between instances of one or more classes. However, it is common to speak of an association between classes, although, strictly speaking, the objects of that class are meant. In the most common case it concerns a relationship between exactly two classes. An association is graphically represented by a line. If more than two types are involved in an association, this is represented by a diamond with lines leading to the objects. A reflexive association, on the other hand, exists between instances of the same class. The cardinalities of an association specify how many objects of the participating class know a particular object. A distinction is made between can and must associations: an can association has a cardinality of 0 as the lower limit, a must association a cardinality of 1 or greater. An indefinite upper limit is indicated by the * symbol. Associations can be named. If the name describes only one direction of the association, the reading direction is indicated by a black triangle or an arrow. If the meaning of the association is obvious, the name can be missing.

Representation of composition and aggregation with cardinalities

An aggregation is a special association that defines a ranking on the connected instances of a class, which can be described by “is part of” or “consists of” ( part-whole relationship ). One speaks of a directed acyclic graph : If B is part of A, then A must not be part of B. If a sub-object can be assigned to several aggregation objects, one speaks of "shared aggregation" (dt. I. E. Shared aggregation) or "weak ownership" (dt. I. E. Weak ownership). In the class diagram, an aggregation is indicated by an empty diamond at the "whole end" of the association line.

A composition is an even stronger form of aggregation. In addition to a part-whole relationship, the following conditions also apply:

  • Each object of the subclass may only ever be a component of a single object of the aggregation class, i.e. H. the cardinality for the aggregation class must not be greater than 1 in each case.
  • If "the whole" is deleted, its parts are also automatically deleted.
  • The dynamic semantics of the whole also apply to its parts. For example, if the whole is copied, its parts are also copied.

In the composition, the "whole end" is indicated by a filled or black diamond.

Representation of generalization or inheritance

The inheritance is used to create new building on existing classes, and the relationship between the original and the new class is permanent. A new class can be an extension or a restriction of the original class. In addition to this constructive aspect, inheritance also serves to document similarities between classes, which is particularly important in the early phases of software design. Class hierarchies based on inheritance reflect structural and behavioral similarities of the classes. The inheriting class is usually called the base class (also called the parent class), the inheriting derived class (child class). The process of inheritance is usually called derivation or specialization, the reverse of this is called generalization , which is a term that is mainly limited to the model level . In the UML, an inheritance relationship is represented by an arrow with a triangular tip pointing from the derived class to the base class. Inherited attributes and operations are not repeated in the representation of the derived class.

Object diagram

An object diagram can be viewed as a special case of the class diagram. While a class diagram models the general “templates” and all possible relationships between the objects, the associated object diagram shows the objects actually created, their attribute values ​​and relationships within a limited period of time. The display therefore typically includes specification specifications of classes and associations. How an object behaves in a certain situation depends largely on its state. This results from the specific value assignment of its attributes.

Example of occurrence specification for an object relationship

The graphical representation of an object is very similar to that of a class. Objects are also represented by rectangles. In the first field the object name is given together with the type. The name of the object is underlined to distinguish it from the class notation. In the second field, attributes are listed with their names and an exemplary or current value in the respective context. Operations are not mentioned because they have no object-specific characteristics and are identical for all objects of a class. Instead, the concrete exchange of messages between objects is shown in communication and sequence diagrams.

The behavior of an object-oriented system is described by messages (also called messages) with which objects communicate with one another. Objects act in the functions of senders (clients) and receivers (suppliers): The sender sends a message with the request to provide a service. A message consists of a selector (a name), a list of arguments and is sent to exactly one recipient. The recipient interprets this message and performs an operation. However, the sender of the message does not know how the corresponding operation is carried out ( secret principle ).

A current relationship between objects is called a link or object relationship. A link describes the concrete relationship between two objects of a class and can therefore be understood as an instance of an association. Similar to the association in the class diagram, it is shown as a line between the objects. At the respective ends of the connection there can be role names that describe the behavior of the objects in more detail.

Dynamic modeling

use cases

With applications (Engl. Use cases) the externally observable functions are specified, that is what is supposed to provide an application system to a user. An actor is a unit outside the system that is involved in the interaction with the system. This can be a person, but it can also be a technical system such as an operating system or a printer . The following rules must be observed:

  • At least one actor is involved in each use case.
  • Every use case has a technical trigger.
  • Each use case produces a technical result that is relevant for the actors, i. H. a result of "business value".
Use case diagram with use cases SMS verschickenandFotomessage verschicken

Use cases are classically named as the goals are called from the point of view of the actors: register a member , withdraw money , return a car, etc. The granularity of use cases can vary greatly: At a very high level, a use case only describes what happens very roughly and abstractly. However, the use case writing technique can be refined down to the IT process level so that the behavior of an application is described in detail. This contradicts the original intention of use cases, but is sometimes useful.

The content structure of a use case usually follows a template to be defined, which must be worked out depending on the context of the later use of the use case. Mostly, differently formalized templates are used for different analysis phases, from the purely prosaic short description to a complete, elaborated application. Alistair Cockburn , for example, describes how "use cases" should be structured and which components belong in them (see also Structure of a Use Case ).

A use case diagram represents use cases and actors with their respective dependencies and relationships. It is thus a behavior diagram that specifies the expected behavior of a system, and not a description of the process, such as a sequence or communication diagram.

A use case diagram contains a set of use cases represented by individual ellipses and a set of actors who are involved in them. These are connected by lines with the corresponding use cases. A frame around the use cases symbolizes the system boundaries.

Sequence diagram

A sequence of processing steps that has to be carried out under certain conditions is called a scenario. These steps should realize the main objective of the actor and deliver a corresponding result. There are two categories of scenarios: those that describe successful processing of the business process, and those that lead to a failure. Scenarios are represented by interaction diagrams. The UML offers two types of diagrams for this: the sequence diagram and the communication diagram. Sequence diagrams put the chronological sequence in the foreground, communication diagrams, on the other hand, show the principle of cooperation.

Example of a sequence diagram between occurrences of the classes Kochand Herdwith the messages "switch on" and "switch off"

Scenarios are to be modeled so precisely in sequence diagrams that their technical correctness can be discussed in order to create a suitable specification for design and implementation. Sequence diagrams describe the exchange of messages between versions by means of lifelines and usually represent a path through a decision tree within a system flow. They have two dimensions: the vertical represents the time, the objects are entered on the horizontal.

Each object involved is represented as a rectangle and a dashed vertical line underneath, the lifeline, symbolizes its existence during a certain period of time. A message is represented on a sequence diagram by an arrow, with the name of the message written above the arrow. Synchronous messages are shown with a filled arrowhead, asynchronous messages with an open arrowhead. Messages that correspond to asynchronous signals are represented in the same way as asynchronous operation calls. The main difference between asynchronous and synchronous messages is that the synchronous messages “block” the outgoing lifeline for further messages until it has received a response. This is not the case with asynchronous messages. The narrow rectangles that lie on the lifelines are activation bars that indicate the "focus of control", ie the area in which an object has control flow and is actively involved in interactions.

Conditions are given in square brackets, that is, in the form [Bedingung] Operation {}. The specified operation is therefore only called if the condition is met. Repetitions are represented by * [Bedingung] Operation {}.

A sequence diagram must be consistent with the class diagram; H. all messages that are sent to an object of a class must be contained in the class diagram in the operation list of this class.

Communication diagram

Communication diagram that corresponds to the sequence diagram above

The communication diagram corresponds to the collaboration diagram of UML 1.X. It has been renamed as the name Collaboration Diagram is misleading. The UML also has the model element collaboration, but this has nothing to do with the “collaboration diagram”.

A communication diagram documents the cooperation between objects and is very close to the object diagram. In contrast, however, it does not model a snapshot of the system structure, but rather shows how the objects work together to perform a particular operation. In addition to the links between the objects, it also shows the messages that these send to each other. This is entered in the form of an arrow pointing to the receiving object at the connection between two objects. A label on the arrow shows the content of the message. Usually the message tells the receiving object that it should carry out one of its operations.

Objects that are newly created during execution are marked with {new}, objects that are deleted during execution are {destroyed}marked with . Objects that are both created and deleted during execution are {transient}. Similarly, object connections that are created in the course of execution can be labeled with {new}, deleted links with {destroyed}and connections that are both established and dismantled within the scenario with {transient}.

State diagram

The behavior of a washing machine as a state machine is modeled in a state diagram

The state of an object is determined by its attribute values. Depending on what state an object is in, it can react differently to the same incoming messages. This behavior of objects can be modeled by state machines: This is a set of states and a transition function that determines the subsequent state depending on the current state and the incoming event.

The states are shown in the state diagram as rounded rectangles and must have different names. A state transition (transition) is represented as an arrow from the initial state to the new state. A transition is labeled with the name of the event (trigger) that triggers this transition. There are two special states: the start state and the end state. Each state machine can only have one start state. The start state is marked in the diagram as a black filled circle and the end state as a black filled double circle.

Object-oriented design

The aim of object-oriented design is system planning with objects that influence each other and to solve programming problems. In contrast to the functional specification , the object-oriented design also takes into account technical aspects of the system and aims at the realization of the requirements - and not at their understanding. However, this design is still on a higher level of abstraction than the actual implementation in a programming language.

In the transition from the analysis to the design phase, the analysis model and the classes specified in it are expanded and improved. The point is to get a model of the program system to be implemented. You model a specific implementation in the solution area and its associated hardware and software environment. In the approach of Coad and Yourdon, the OOD is broken down into four components in which the previous analysis model is revised and expanded: the problem area component, the communication component, the data management component and the task management component.

Problem area component

In this phase the results of the analysis phase are revised and improved in order to prepare the implementation of the classes. For example, attributes, object relationships and classes can be added or deleted. The aim is to model self-contained classes of adequate complexity.

According to Heide Balzert , a common, albeit incorrect, idea is that all concrete objects in the problem area can be found as a class in the analysis model. For example, the lack of complex attributes leads to many small classes and, as a result, to many superfluous associations. This makes the overall model more difficult to understand.

The term coupling describes the link between classes and is a measure that describes the strength of these links or the resulting dependencies. The coupling of objects through operation calls should be kept as low as possible, but as high as necessary in order to obtain understandable independent classes, and the desirable cohesion of classes and their individual operations.

The Cohesion describes how well a class maps a logical task or unit. In a system with strong cohesion, each class is responsible for exactly one well-defined task or unit. The single responsibility principle states that each class only has to fulfill exactly one clearly defined task. This task is fulfilled by the interaction of all attributes and methods of this class. The interaction of the attributes and methods of this class is therefore very close. One speaks of strong cohesion.

If the cohesion is too weak, this leads, among other things, to the fact that common functionalities of a class are not reused, but are implemented several times. Code duplication is therefore a sign of poor cohesion. The DRY principle ( D on't R epeat Y ourself - 'Don't repeat yourself') helps to avoid this.

The inheritance structure should also be revised in the design. In the analysis, operations that apply to several subclasses are inserted as “high as possible” into the inheritance structure, provided they have a common description. According to Balzert and Wirfs-Brock et al. It is a good idea to create as many abstract classes as possible because it makes adding new classes easier. An abstract class is a special class which cannot be instantiated and which therefore only serves as a structural element within a class hierarchy. This takes full advantage of the concept of inheritance.

The inheritance mechanism can also lead to attributes and operations being “collected” in a class only for the purpose of saving the programmer writing effort. In this context, one also speaks of “Spaghetti Code”. Such arbitrarily created classes are easy to recognize: The class name has no meaningfulness or has no relation to the attributes and operations of the class.

Communication component

Input device (tablet) and viewing device (display) for communication between humans and computers.

The design activities of this component deal with how a user operates the system and, conversely, how the system presents results and information to the user, which is why it is also called human-computer communication component. The user interface should be tailored directly to the future user. For this purpose, new classes on the system boundary are being developed.

An important starting point for this design activity are the scenarios from dynamic modeling, for whose classes the attributes to be input or output and the associated access functions were already defined during the analysis phase. In addition to the attributes and methods already defined in the analysis phase, details on layout, user inputs and the behavior of windows are now added. A clear separation between the classes of the communication component and the classes of the problem area component is necessary in order to make the system more stable with regard to modifications.

Data management component

When designing this component, the data aspects of the system are studied and the requirements for saving and retrieving objects are created. Important aspects are integrity d. H. the prevention of unauthorized modification of information and consistency , d. H. the correctness of the data stored in the database.

Persistent objects can be kept in three different ways:

  • The objects to be saved (or their attribute values) are copied into text files using the language provided for the implementation.
  • The objects are copied into the tables of a relational database system and the use of its protective mechanisms.
  • An object-oriented database is used.

Task management component

This component is designed to coordinate the objects and their methods, specifically for the case that the behavior of different objects is to be modeled in parallel in the system or the communication between the objects is to be modeled asynchronously. For this purpose, classes are designed which define the starting and scheduling of the various tasks (or also: processes), the activities and actions to be carried out by them, as well as interprocess communication and task priorities. In order to be able to realize the simultaneous or seemingly simultaneous processing of several tasks, a multi-processor machine or a multi-tasking operating system must be available. As a rule, a special task class library is used. Usually, tasks can assume the states “running”, “suspended” or “terminated”.

literature

  • Heide Balzert : Textbook of object modeling. Analysis and design. Spectrum: Heidelberg, Berlin, 1999.
  • Grady Booch et al .: Object-Oriented Analysis and Design with Applications. Third Edition, Addison-Wesley: Boston MA, 2007.
  • Peter Coad , Edward Yourdon : Object-Oriented Analysis. Englewood Cliffs, NY, 2nd edition, 1990 (German: Object Oriented Analysis. 1994)
  • Peter Coad, Edward Yourdon: Object-Oriented Design. Englewood Cliffs, NY, 1991. (German: Object-Oriented Design. 1994)
  • Ivar Jacobson , Grady Booch, James Rumbaugh : The unified software development process. UML. Addison-Wesley: Reading MA a. a., 1999.

Individual evidence

  1. ^ Christian Aichele, Marius Schönberger: IT project management. Efficient introduction to the management of projects. Springer: Wiesbaden, 2014, p. 29; Manfred Broy, Marco Kuhrmann: Project organization and management in software engineering. Springer: Berlin, 2013, p. 85.
  2. ^ Heide Balzert: Textbook of object modeling. Analysis and design. Spectrum: Heidelberg, Berlin, 1999, p. 2.
  3. ^ Peter Coad, Edward Yourdon: Object-Oriented Analysis. Englewood Cliffs, NY, 2nd edition, 1990.
  4. ^ Peter Coad, Edward Yourdon: Object-Oriented Design. Englewood Cliffs, NY, 1991.
  5. ^ Philippe Kruchten: The Rational Unified Process. An Introduction. Addison-Wesley: 2nd edition, 2004.
  6. ^ Grady Booch, Robert A. Maksimchuk, Michael W. Engle, Bobbi J. Young, Jim Conallen, Kelli A. Houston: Object-Oriented Analysis and Design with Applications. Third Edition, Addison-Wesley, 2007, p. 41.
  7. ↑ Gert Heinrich , Klaus Mairon: Object-oriented system analysis. Oldenburg Verlag: München, 2008, p. 57.
  8. ↑ Helmut Balzert: Textbook of software technology. Basic concepts and requirements engineering. Spectrum: Heidelberg, 3rd edition, 2009, p. 434.
  9. ↑ Helmuth Partsch: Systematic Requirements Engineering. Modeling for software-based systems. Springer: Berlin, Heidelberg, 1998, p. 213.
  10. ^ Balzert: Textbook of software technology. Basic concepts and requirements engineering. 3rd edition, 2009, p. 456.
  11. ^ Balzert: Textbook of software technology. Basic concepts and requirements engineering. 3rd edition, 2009, p. 463.
  12. ^ Balzert: Textbook of software technology. Basic concepts and requirements engineering. 3rd edition, 2009, pp. 475-476.
  13. ^ Balzert: Textbook of software technology. Basic concepts and requirements engineering. 3rd edition, 2009, p. 477.
  14. ↑ DIN 69901, 2009, p. 153
  15. ^ A b Aichele, Schönberger: IT project management. 2014, p. 23.
  16. ↑ DIN 69901, 2009, p. 154
  17. ↑ Gert Heinrich, Klaus Mairon: Object-oriented system analysis. Oldenburg Verlag: München, 2008, p. 17.
  18. ↑ Balzert: Textbook of object modeling. 1999, p. 40.
  19. ↑ Balzert: Textbook of object modeling. 1999, pp. 40-43.
  20. ↑ Balzert: Textbook of object modeling. 1999, pp. 46-47.
  21. ↑ Balzert: Textbook of object modeling. 1999, p. 47.
  22. ↑ Bernd Oestereich: The UML short reference for practice. Short, to the point, ballast-free. 2nd revised edition: 2002, pp. 22–23.
  23. ↑ Austria: The UML short reference for practice. 2nd edition 2002, p. 5.
  24. ↑ Alistair Cockburn: Creating Use Cases effectively. mitp: Heidelberg, 2003.
  25. ↑ Balzert: Textbook of object modeling. 1999, pp. 70-71.
  26. ↑ Balzert: Textbook of object modeling. 1999, pp. 76-77.
  27. ^ Seemann, von Gudenberg: Software design with UML 2. 2006, pp. 106–110.
  28. ↑ Balzert: Textbook of object modeling. P. 145.
  29. ↑ Schader, Rundshagen: Object-oriented system analysis. Pp. 143-144.
  30. ↑ Balzert: Textbook of object modeling. P. 379; Rebecca Wirfs-Brock, Brian Wilkerson, Lauren Wiener: Designing Object-Oriented Software. Prentice Hall: Englewood Cliffs, 1990, pp. 140ff.
  31. ↑ Schader, Rundshagen: Object-oriented system analysis. Pp. 144-147.
  32. ↑ Schader, Rundshagen: Object-oriented system analysis. Pp. 147-150.
  33. ↑ Schader, Rundshagen: Object-oriented system analysis. P. 151.