Elaboration (Entwurfsphase)

Transkript

1 Elaboration (Entwurfsphase) Die Elaboration dient der Analyse des Anwendungsbereiches und der Erfassung der funktionalen und nichtfunktionalen Anforderungen an das Produkt. Die fachlichen Zusammenhänge und Anforderungen sind detailliert zu ermitteln, die fachliche Architektur und die Anwendungsarchitektur sind zu erarbeiten und die Projektplanung ist zu detaillieren. Erste Lösungskonzepte werden entwickelt. Die Entwurfsphase kann in ein oder zwei Iterationen durchgeführt werden. Martin Jud Software-Engineering Construction Analysemodell 1 Aus dem Object Engineering Process 1999 by oose.de / B. Oestereich Ergebnisse der Elaboration C-Requirements abschliessen final draft D-Requirements Anwendungsarchitektur Entwurf Iterationsplan Construction Verfeinerte Risikobetrachtung => Soweit sinnvoll werden Prototypen und auch schon erste Komponenten entwickelt. Martin Jud Software-Engineering Construction Analysemodell 2

2 Aktivitäten der Elaboration Anforderungsanalyse (UseCases vervollständigen / nichtfunktionale Anforderungen / Analyse-Klassenmodell) Fachliche Architektur (Geschäftsklassen / Ablauf- und Aktivitätsmodelle / Architekturmodell) Komponentenmodell (Subsysteme / Komponenten / Schnittstellen) Analyse Modell Architektur Modell Planung (Risikoanalyse / Testplanung / Entwicklungsumgebung / Rollende Planung Construction) Martin Jud Software-Engineering Construction Analysemodell 3 Real World Project C-Requirements (SRS chap.2) Modelle Use Case Feature List Analysis Model D-Requirements (SRS chap. 3) System Subs. Subs. Subs. Req. mapped to Software: Subsystems System Design (SDD chap. 2/3) Architecture Model... Communication-View Prozess-View System Subs. Subs. Subs. Design Model Detailed Design (SDD chap. 4/5) class XY {... f1(); } Code Martin Jud Software-Engineering Construction Analysemodell 4 Nach einer Idee von Jörg Hofstetter HTA Luzern

3 Concurrent Development of Requirements and Architecture Martin Jud Software-Engineering Construction Analysemodell 5 Aus einem STRAW 01 Paper von Bashar Nuseibeh Das Analysemodell Das Analysemodell besteht aus: Dem Analyse-Klassenmodell mit den Stereotypen «entity», «boundary» oder «control» Sequenzdiagrammen die beschreiben, wie diese Klassen zusammenspielen Dem konzeptionellen Datenmodell, ein redundanzfreies ER-Modell Martin Jud Software-Engineering Construction Analysemodell 6

4 das Analyse-Klassenmodell ein UML-Klassenmodell, welches das Problemverständnis repräsentiert, d.h. Anforderungen beschreibt, keine Lösungen. enthält nur UML-Basiskonstrukte und sollte ansatzweise auch mit AnwenderInnen und Fachabteilungsmitarbeiter-Innen diskutierbar sein. es ist nicht notwendig, dass das Analyse-Klassenmodell auf ein Design-Klassenmodell abgebildet werden kann. Martin Jud Software-Engineering Construction Analysemodell 7 Aus dem Object Engineering Process 1999 by oose.de / B. Oestereich Anforderungsmodell & Analysemodell Browse Course Catalog [else] Customer Select Course Info aus Aktivitäten des Geschäftsprozessmodells werden UseCases des Systemanforderungsmodells Enter Personal Data [data correct] Confirm Registration Register for Course Request for Information Billing Customer Send Comment jeder UseCase wird durch Klassen mit den Stereotypen «entity» «boundary» oder «control» verfeinert. 1..* Bank Kunde Geldausgabe Abhebung User Interface Konto besitz 1..* Transfer Konto aus Instanzen des Geschäftsprozessmodells werden Klassen im Analysemodell. Geldannahme Einzahlung Martin Jud Software-Engineering Construction Analysemodell 8 Sinngemäss aus Realisierung einer Unternehmensanwendung by Günter Ruck, MID GmbH

5 Analysis Class Stereotypes Analysis classes may be stereotyped as one of the following: Boundary classes Control classes Entity classes These stereotypes are specially useful in helping you to identify classes in analysis and early design. Martin Jud Software-Engineering Construction Analysemodell 9 UML Stereotypen für Analyse-Modelle Boundary-Klassen: Klassen für die Präsentation und Manipulation. Jeder Aktor eines UseCases benötigt ein eigenes Boundary-Objekt. z.b.: Window, Dialogbox, Komm.-kanal Control-Klassen: Verbinden Boundary-Klassen mit ihren Entity-Klassen. Behandeln das Verarbeiten der Entity- Klassen. In einem ersten Schritt kann gesagt werden: Für jeden UseCase eine Control-Klasse. Entity-Klassen: Modellieren Information, die meist auch gespeichert werden muss. Business-Objekte. Martin Jud Software-Engineering Construction Analysemodell 10 Aus der Vorlesung SW-Architektur von Jörg Hofstetter HTA Luzern

6 Boundary Classes A boundary class is a class used to model interaction between the system's surroundings and its inner workings. Such interaction involves transforming and translating events and noting changes in the system presentation (such as the interface). Common boundary classes include windows, communication protocols, printer interfaces, sensors, and terminals. Boundary classes are also useful for capturing interfaces to possibly non object-oriented API's, such as legacy code. Boundary classes may help identifying related services. For example, if you identify a printer interface early in the design, you will soon see that you must also model the formatting of printouts. Martin Jud Software-Engineering Construction Analysemodell 11 Types of Boundary Classes A system may have several types of boundary classes: User interface classes - classes which intermediate communication with human users of the system System interface classes - classes which intermediate communication with other system Device interface classes - classes which provide the interface to devices (such as sensors), which detect external events Martin Jud Software-Engineering Construction Analysemodell 12

7 Control Classes A control class is a class used to model control behavior specific to one or a few use cases. Control objects (instances of control classes) often control other objects. The behavior of a control object is closely related to the realization of a specific use case. In many scenarios, you might even say that the control objects "run" the use-case realizations. You can start by identifying one control class per use-case realization, and then refine this as more use-case realizations are identified and commonality is discovered. Control classes can contribute to understanding the system because they represent the dynamics of the system, handling the main tasks and control flows. Note that a control class does not handle everything required in a use case. Instead, it delegates work and coordinates the activities of other objects that implement the functionality. Martin Jud Software-Engineering Construction Analysemodell 13 Entity Classes An entity class is a class used to model information and associated behavior that must be stored. Entity objects (instances of entity classes) are used to hold and update information about some phenomenon, such as an event, a person, or some real-life object. They are usually persistent. An entity object may also be needed to help perform internal system tasks. Entity objects can have behavior as long as this behavior is strongly related to what the entity object represents. Entity objects represent the key concepts of the system being developed. Typical examples of entity classes in a banking system are Account and Customer. In a network-handling system, examples are Node and Link. If the phenomenon you wish to model is not used by any other class, you can model it as an attribute of an entity class, or even as a relationship between entity classes. On the other hand, if the phenomenon is used by any other class in the design model, you must model it as a class. Martin Jud Software-Engineering Construction Analysemodell 14

8 Klassendiagramme Klassendiagramme sind der zentrale Bestandteil der UML. Allerdings gibt die UML keine Auskunft darüber, wie die Klassen ermittelt werden. Techniken hierfür: CRC-Karten (Class, Responsibility and Collaboration) die Substantiv-Technik (vgl. [Rumbaugh 91]). Martin Jud Software-Engineering Construction Analysemodell 15 Finden geeigneter Klassen und Objekte Man kann eine Problemstellung aufschreiben, die Substantive und Verben unterstreichen und entsprechende Klassen und Methoden konstruieren, oder man kann sich auf die Interaktionen und die Zuständigkeiten in Ihrem System konzentrieren, oder man modelliert die reale Welt und überführt bei der Analyse gefundene Objekte in den Entwurf. Martin Jud Software-Engineering Construction Analysemodell 16

9 Finding Classes CRC Cards Class Name RegistrationManager Responsibilities Collaborations administrate participants administrate courses Course Participant Martin Jud Software-Engineering Construction Analysemodell by SWEED, Martin Kropp Boundary: Find User-Interface Classes Boundary classes representing the user interface may exist from userinterface modeling activities; where appropriate, re-use these classes in this activity. In the event that user-interface modeling has not been done, the following discussion will aid in finding these classes. There is at least one boundary object for each use-case actor-pair. This object can be viewed as having responsibility for coordinating the interaction with the actor. This boundary object may have subsidiary objects to which it delegates some of its responsibilities. This is particularly true for windowbased GUI applications, where there is typically one boundary object for each window, or one for each form. Make sketches, or use screen dumps from a user-interface prototype, that illustrate the behavior and appearance of the boundary objects. Only model the key abstractions of the system; do not model every button, list and widget in the GUI. The goal of analysis is to form a good picture of how the system is composed, not to design every last detail. In other words, identify boundary classes only for phenomena in the system or for things mentioned in the flow of events of the use-case realization. Martin Jud Software-Engineering Construction Analysemodell 18

10 Boundary: Find System-Interface Classes A boundary class which communicates with an external system is responsible for managing the dialogue with the external system; it provides the interface to that system for the system being built. Example In an Automated Teller Machine, withdrawal of funds must be verified through the ATM Network, an actor (which in turn verifies the withdrawal with the bank accounting system). An object called ATM Network Interface can be identified to provide communication with the ATM Network. The interface to an existing system may already be well-defined; if it is, the responsibilities should be derived directly from the interface definition. If a formal interface definition exists, it may be reverse engineered and we need not formally define it here; simply make note of the fact that the existing interface will be reused during design. Martin Jud Software-Engineering Construction Analysemodell 19 Boundary: Find Device Interface Classes The system may contain elements that act as if they were external (change value spontaneously without any object in the system affecting them), such as sensor equipment. Although it is possible to represent this type of external device using actors, users of the system may find doing so "confusing", as it tends to put devices and human actors on the same "level". Once we move away from gathering requirements, however, we need to consider the source for all external events and make sure we have a way for the system to detect these events. If the device is represented as an actor in the use-case model, it is easy to justify using a boundary class to intermediate communication between the device and the system. If the use-case model does not include these "device-actors", now is the appropriate time to add them, updating the Supplementary Descriptions of the Use Cases where appropriate. For each "device-actor", create a boundary class to capture the responsibilities of the device or sensor. If there is a well-defined interface already existing for the device, make note of it for later reference during design. Martin Jud Software-Engineering Construction Analysemodell 20

11 Finding Control Classes Control classes provide coordinating behavior in the system. Examples of control objects include programs such as transaction managers, resource coordinators, and error handlers. Control classes provide behavior that: Is surroundings-independent (does not change when the surroundings change), Defines control logic (order between events) and transactions within a use case. Changes little if the internal structure or behavior of the entity classes changes, Uses or sets the contents of several entity classes, and therefore needs to coordinate the behavior of these entity classes. Is not performed in the same way every time it is activated (flow of events features several states). The flows of events should be encapsulated in a separate control class when it is complex and consists of dynamic behavior that may change independently from the interfaces (boundary classes) or information stores (entity classes) of the system. Martin Jud Software-Engineering Construction Analysemodell 21 Finding Entity Classes Entity classes represent stores of information in the system; they are typically used to represent the key concepts the system manages. Entity objects are frequently passive and persistent. Their main responsibilities are to store and manage information in the system. A frequent source of inspiration for entity classes are the Glossary (developed during requirements) and a business-model. Martin Jud Software-Engineering Construction Analysemodell 22

12 Zusammenhang UseCase => Analyse-Klassen «trace» Bargeld abheben Geldausgabe Abhebung User Interface Bargeld einzahlen Geldannahme Einzahlung Konto Kontentransfer Transfer Martin Jud Software-Engineering Construction Analysemodell 23 Geldautomat: Analyse Modell Kontobesitz 1..* Geldausgabe Abhebung * Bank Kunde User Interface Transfer 1 Konto Geldannahme Einzahlung Martin Jud Software-Engineering Construction Analysemodell 24

13 Assoziationen Die Assoziation stellt eine allgemeine Beziehung zwischen zwei Klassen dar, über die Realisierung wird dabei nichts ausgesagt. Die Aggregation ist eine besondere Assoziation, die durch eine Raute an der Linie dargestellt wird. Sie gibt an, dass z.b. die Klasse Kartenleser in der Klasse Geldautomat "enthalten" ist (Ist- Teilvon- Beziehung). Die Komposition ist eine stärkere Form der Aggregation, die durch eine ausgefüllte Raute dargestellt wird (siehe Tresor). Bei der Beziehung Komposition handelt es sich um ein physisches enthalten sein. Martin Jud Software-Engineering Construction Analysemodell by OBJEKTspektrum, Günter Wahl Assoziation: benutzt-beziehung Modelliert eine allgemeine Beziehung zwischen Klassen Land Name hat zur Hauptstadt Stadt Name Bremskraftregler meldet blockiert Sensor Assoziation = Menge aller Verbindungen zwischen den Objekten der beteiligten Klassen Meist als Zeiger implementiert (Java Objektreferenz) Assoziationsname optional Martin Jud Software-Engineering Construction Analysemodell 26

14 Kardinalität von Assoziationen Bestimmt die Anzahl Verbindungen zwischen den Klassen A B 2 3 A B Jedes A ist genau mit einem B verbunden Jedes A ist mit 3 B verbunden Jedes B ist mit 2 A verbunden A 2..4 B Jedes A ist mit B verbunden A 0..1 B Jedes A ist mit 0..1 B verbunden (optional) A * B Jedes A ist mit 0.. B verbunden Martin Jud Software-Engineering Construction Analysemodell 27