Chapter 11- 313 key terms and confusing stuufff

Dear Lord why so much content for one exam

Control classes and their role in the flow of applications

A software application is a dynamic entity. Consequently, its usability depends on how well it flows and how successfully it can control and direct its building blocks towards goals that the application must help its users to achieve. Objects that control the flow of the application, direct the sequencing of events, manage the interaction among objects, and encapsulate the behavior specified by use cases are called control objects. Aseemingly simple message from the user interface, such as “update the patient profile,” uually translates into a set of messages that the control objects direct towards entity and other design objects such as those responsible for persisting the data in a database. The central concept behind control objects is a

rule that flows from object-oriented design: divide and conquer. By distributing the responsibilities of the solution among control and flow objects, the user interface, persistence, and entity objects can remain focused on their own responsibilities.

Building on analysis models

Design focuses on the product that solves the problem, but it is not a sudden break with analysis. On the contrary, design is an evolution from a conceptual solution to a concrete one. The same evolutionary path is also followed by individual building blocks of design. Concrete modeling revisits use cases from the viewpoint of design and develops its artifacts by expanding structural and dynamic models of analysis. Analysis and design are two sides of the same coin. Nevertheless, they look at opposite directions to define their structural entities. In analysis, the process of defining entity classes is primarily a process of discovery: what objects in the problem space must be abstracted into the entity classes of the information systems. Design, by contrast, arrives at concrete classes by invention: what entities would answer the needs of the solution space.

 Characteristics of flow objects 

Flow objects enforce the workflow and the sequencing of events as specified by behavioral modeling, as described by use cases, and by dynamic models. To enforce the workflow, flow objects must intercept most messages exchanged between objects to ensure that the interaction between them follows the correct sequence or scenario.

One important result of this intervention is that other objects can retain their clear, specific, and specialized missions:

• The user interface can focus on presenting data to the user and accepting data from the user. It does not have to retrieve data from the database or save it.

• Persistence objects, those objects that manage the interaction with external data sources, can hide the complexities of data management from other components of the applications. Furthermore, they are not charged with controlling how the data is consumed or by whom.

• Entity objects can remain as independent from specific applications as possible. Thus, besides command and control, flow objects provide other objects with services that they cannot find for themselves. The services that the flow object provides are usually not its own, but are delegated to other entity and design objects. Without flow objects, boundary and entity objects would have to assume responsibilities that would reduce their flexibility and increase their complexity.

Applying structural modeling to design

The ultimate mission of concrete modeling is to produce blueprints for building the information system and its components. This task involves both the refinement of entity classes that originate from the problem domain and the definition of design classes that serve the solution. Design classes are not abstractions of objects that have counterparts in the problem domain. Therefore, to define their responsibilities, we must parse dynamic models, such as sequence diagrams, that identify services that the solution requires. In other words, we can define design classes by studying the needs that we discover when we reintegrate the flow of use cases with classes from analysis.

 Life cycle objects

 Life cycle classes are responsible for managing a set of other objects, especially when a large number of entity classes are involved. They create, organize, track, and destroy other objects, often instances of entity classes.

Life cycle objects help both the management of complexity and reuse. Life cycle classes have similar missions; therefore, they have similar attributes and operations as well: They are collections, responsible for managing multiple objects, from a few to thousands; they provide a set of navigational operations such as first, next, previous, and last that allow outside entities to browse among objects within the collection; they expose individual objects upon request; they provide lists of objects in their care; they often provide operations such as search or find to select subsets that satisfy specific criteria.

Dataset, a utility object

Besides control and flow, the internal workings of an application require a wide range of utility objects. One such object is dataset, which, depending on technology, is also called resultset, recordset, or simply list. Data are values and as values they must have containers. Messages exchanged between objects carry data in containers called “variables,” the same type of containers that objects use privately to hold the values for their attributes. This mechanism, however, would be unwieldy and inefficient for carrying large amounts of data among objects.

To arrive at blueprints for building methods,

Dataset is a general-purpose utility object that carries data between objects within an application. It is a collection object in which the objects are organized as rows and columns, similar to spreadsheets. Each cell within this tabular format is a “primitive” object that exposes a single piece of data of a certain type. This data type is the same for all members of the column. The exact variety of data types depends on the technology and language, but they fall in general categories of string (text), number, Boolean, or object (or rather, the address of an object)

 Application control & security

 The control of an application is composed of control objects for individual use cases, plus objects that control application-level flow, including security enforcement objects. The difference between the flow of an application and the flow of its individual use cases is a difference in scope, not in quality. Both flows must enforce a predetermined sequence of actions, including conditional steps (or the “alternate flow”). Typically, a large application is usually made of multiple “mini-apps,” each with its own flow objects. Security and user privileges are usually decided when the user logs into the application and are communicated to individual control objects as the need arises.

The application flow does not directly interact with entity objects. In general, the interaction of the application flow should be limited to other control objects, including security and flow objects that perform application-specific services such as those that display menus and return user selection.

Design requirements for defining methods & messages

 Messages are how objects interact within an object-oriented context. To define a concrete class, we must provide it with exact and detailed methods so that its instances can respond to exact and unambiguous messages from other objects and provide them with its services. Methods are implementations of an object’s public services. To ask an object to perform a service, another object must send it a message that corresponds both in substance and in form to the method that provides the service.To arrive at blueprints for building methods, we must progressively refine messages into detailed logical and physical models. For concrete modeling, parameters within a method must be clearly specified: Methods cannot rely on guesswork. We must also define the data type for each parameter. Furthermore, concrete modeling of methods requires not only the specification of substance, but also of the form.

Methods implement not only operations,

but also provide access to attributes. Such methods are called accessor methods and are

usually defined in pairs, one for reading the value of the attribute and the other for setting it. By removing one, we can make an attribute read-only or write-only. Amethod’s name, its parameters, the type and

the relative position of each parameter, and the type of its return value are known collectively as the method’s signature. Overloading is a mechanism by which you may define several methods with the same name but with different signatures.

 Construction and destruction of objects 

Objects do not create themselves: Each object must be instantiated by another object. In most object-oriented languages, an object may implement constructor methods that allow the entity that instantiates the object to provide it with information that it needs from inception to provide any service. Constructors are like other methods and can even be “overloaded,” but they have the same name as the class and cannot be accessed after the object has been instantiated. Destruction of objects often does not require explicit actions: When other objects no longer refer to an object, it is automatically destroyed by the runtime environment. Sometimes, however, you need to destroy objects explicitly.

 The control flow of Web applications 

The state of an application is a snapshot of the application in time. By keeping state, an application “knows” what the user has been doing, where in the workflow the user is now, and what actions are allowed or possible from this point on. The Web, however, is a “stateless”

environment: AWeb server does not keep track of the identity or the actions of the users after responding to individual messages. AWeb application, therefore, must recreate the state every single time that it receives a message from the Web. The mechanisms by which Web developers keep the state of an application are varied. In essence, the Web application recreates the state each time it receives a message from the client by analyzing a “marker” that it has transmitted to the client in the previous exchange. The most common form of such a marker is a small text file called a cookie that encodes the necessary data for building the state. Another method is to encode the “state data” inside the URL (Uniform Resource Locator), also known as a link, that is clicked by the user to send a message to the Web server.

Accessor Methods.

 Methods that make an object’s attributes accessible to the outside world. They are usually done in pairs, one for reading the value of the attribute and one for setting it. By removing one, the attribute can be made into “read-only” or “write-only.”

Application.

 Adynamic composite of control, entity, boundary, and utility objects that provides specific solutions for information needs. The task of an application is to permit users of an information system to maintain and make sense of a set of entity objects.

 Arguments. 

See Parameters.

 Constructor Method.

 A method with the same name as the class that is executed when an object is instantiated. It is often used to supply the object with information that it needs from the start to perform its services. It cannot be called again after the object has been instantiated. (See Method Overloading.)

Control, Application.

The composite of: 

❶ flow objects for individual use cases and 

❷ objects that direct the application-level flow, including security-enforcement objects.

Control Class.

A class whose instances control the flow of the application, direct the sequencing of events, manage the interaction among other objects, and often encapsulate control related to a specific use case.

Dataset.

A general-purpose utility object that carries data between objects within an application. A dataset is a collection object that organizes objects in a tabular format, as rows and columns. Each cell within the dataset is a “primitive” object that exposes a single piece of data of a certain type.

Data Type.

Identifies the type of data, depending on the platform and language. Usually number, string (text), Boolean (true/false), data, or (the address of an) object.

Entity Classes.

Classes that result from the analysis of objects within the problem domain. Entity classes usually have counterparts in the problem domain.

 Flow Class.

 Atype of control class whose instances enforce the workflow and the sequence of events as envisioned by use case and dynamic modeling. Furthermore, flow objects act as intermediaries between entity and other design objects and provide them with services that they cannot perform by themselves.

Life Cycle Object. 

An object responsible for managing a set of other objects, especially when a large number of entity classes are involved. A life cycle object creates, organizes, tracks, and destroys other objects, often instances of entity classes.

Method.

 Implementation of a public service provided by an object. To ask an object to perform a service, another object must send it a message that corresponds in both substance and form to the method that provides the service. Concrete modeling must provide engineering blueprints for the construction of methods.

 Method Overloading.

When more than one method has the same name but different signatures. See also Method Signature. 

 Method Signature.

 A unique combination of a method’s name, its parameters, the type and the relative position of each parameter, as well as the type of its return value. See also Method Overloading.

Parameter

A piece of data or instruction that must be supplied to an object to carry out a specific method. (Parameters are also called arguments.) The type and the ordinal position of each value that must be received for each parameter is decided by the operation defined in the interface of the class to which the object belongs. 

Return Value.

 The response that a message may invoke from the receiving object after the execution of a method is complete. Each method can have only one return value.

State, Application.

Asnapshot of the condition of an application in time. By keeping state, an application “knows” what the user has been doing, where in the workflow the user is now, and what actions are allowed or possible from this point on. 

State, Object. 

An object’s condition at a certain stage and from a certain viewpoint. It is a snapshot of the object at a (usually important) point in time.

Stateless.

An object, a component, or an application that does not or cannot keep state. The Web is a stateless environment; therefore, Web applications must devise mechanisms to keep state.

Variable.

A container to hold data or values.

Web Application.

 An application that runs on the World Wide Web. It must provide the user with the ability to affect the state of the business logic on the server.