Remaining 4 Questions Coming Soon.... Please be Patient...
The Images Cannot be Posted here
Cannot view the Q&A properly then,
Download the Below Content in .doc[Document] format{Includes Diagrams}
Click here to Download
1. What is Object-Oriented Analysis and Design?
During object-oriented design (or simply, object design) there is an emphasis on defining software objects and how they collaborate to fulfill the requirements. For example, a Plane software object may have a tailNumber attribute and a getFlightHistory method.
2. What is UML?
The UML defines various UML profiles that specialize subsets of the notation for common subject areas, such as diagramming Enterprise JavaBeans (with the UML EJB profile).
Three Ways to Apply UML:
· UML as sketch Informal and incomplete diagrams (often hand sketched on whiteboards) created to explore difficult parts of the problem or solution space, exploiting the power of visual languages.
· UML as blueprint Relatively detailed design diagrams used either for 1) reverse engineering to visualize and better understanding existing code in UML diagrams, or for 2) code generation (forward engineering).
· UML as programming language Complete executable specification of a software system in UML. Executable code will be automatically generated, but is not normally seen or modified by developers; one works only in the UML "programming language." This use of UML requires a practical way to diagram all behavior or logic (probably using interaction or state diagrams), and is still under development in terms of theory, tool robustness and usability.
Agile modeling emphasizes UML as sketch; this is a common way to apply the UML, often with a high return on the investment of time (which is typically short). UML tools can be useful, but I encourage people to also consider an agile modeling approach to applying UML.
Three Perspectives to Apply UML:
- Conceptual perspective the diagrams are interpreted as describing things in a situation of the real world or domain of interest.
- Specification (software) perspective the diagrams (using the same notation as in the conceptual perspective) describe software abstractions or components with specifications and interfaces, but no commitment to a particular implementation (for example, not specifically a class in C# or Java).
- Implementation (software) perspective the diagrams describe software implementations in a particular technology (such as Java).
3. UML Use Cases
Definition:
Actors:
Actor is something with behavior, such as a person (identified by role), computer system, or organization; for example, a cashier.
Scenario:
A scenario is a specific sequence of actions and interactions between actors and the system; it is also called a use case instance. It is one particular story of using a system, or one path through the use case; for example, the scenario of successfully purchasing items with cash, or the scenario of failing to purchase items because of a credit payment denial.
Use Case:
A use case is a collection of related success and failure scenarios that describe an actor using a system to support a goal.
4. UML Use Cases and the Use-Case Model
The UP defines the Use-Case Model within the Requirements discipline. Primarily, this is the set of all written use cases; it is a model of the system's functionality and environment.
The Use-Case Model is not the only requirement artifact in the UP. There are also the Supplementary Specification, Glossary, Vision, and Business Rules. These are all useful for requirements analysis, but secondary at this point.
5. Appling UML: Use Case Diagrams
The UML provides use case diagram notation to illustrate the names of use cases and actors, and the relationships between them.
6. UML Domain Model
A domain model is the most important and classic model in OO analysis. It illustrates noteworthy concepts in a domain. It can act as a source of inspiration for designing some software objects and will be an input to several artifacts explored in the case studies.
The quintessential object-oriented analysis step is the decomposition of a domain into noteworthy concepts or objects.
A domain model is a visual representation of conceptual classes or real-situation objects in a domain. Domain models have also been called conceptual models (the term used in the first edition of this book), domain object models, and analysis object models.
Conceptual Classes:
The domain model illustrates conceptual classes or vocabulary in the domain. Informally, a conceptual class is an idea, thing, or object. More formally, a conceptual class may be considered in terms of its symbol, intension, and extension.
· Symbol words or images representing a conceptual class.
· Intension the definition of a conceptual class.
· Extension the set of examples to which the conceptual class applies.
7. Logical Architecture
The logical architecture is the large-scale organization of the software classes into packages (or namespaces), subsystems, and layers. It's called the logical architecture because there's no decision about how these elements are deployed across different operating system processes or across physical computers in a network (these latter decisions are part of the deployment architecture).
8. Package Diagram
A UML package diagram provides a way to group elements. A UML package can group anything: classes, other packages, use cases, and so on. Nesting packages is very common. A UML package is a more general concept than simply a Java package or .NET namespace, though a UML package can represent those and more.
The package name may be placed on the tab if the package shows inner members, or on the main folder, if not.
9. Domain layer and domain model relationship
Tiers: The original notion of a tier in architecture was a logical layer, not a physical node, but the word has become widely used to mean a physical processing node (or cluster of nodes), such as the "client tier" (the client computer).
Layers: The layers of architecture are said to represent the vertical slices.
Partitions: While partitions represent a horizontal division of relatively parallel subsystems of a layer. For example, the Technical Services layer may be divided into partitions such as Security and Reporting.
Layers and partitions
Mixing views of the architecture
10. UML Class Diagrams
Much of the high-frequency class diagram notation can be summarized (and understood) in one figure:
Most elements in the below figure are optional (e.g., +/- visibility, parameters, compartments). Modelers draw, show or hide them depending on context and the needs of the reader or UML tool.
Common UML class diagram notation
UML Operations
One of the compartments of the UML class box shows the signatures of operations. At the time of this writing, the full, official format of the operation syntax is:
Notice there is no return type element, an obvious problem, but purposefully injected into the UML 2 specification for inscrutable reasons. There is a chance that the specification will revert to a UML1-ish syntax, which in any event many authors show and UML tools will continue to support:
Guideline: Assume the version that includes a return type.
Guideline: Operations are usually assumed public if no visibility is shown.
The property string contains arbitrary additional information, such as exceptions that may be raised, if the operation is abstract, and so forth.
In addition to the official UML operation syntax, the UML allows the operation signature to be written in any programming language, such as Java, assuming the reader or tool is notified. For example, both expressions are possible:
public Player getPlayer( String name ) throws IOException
An operation is not a method. A UML operation is a declaration, with a name, parameters, return type, exceptions list, and possibly a set of constraints of pre-and post-conditions. But, it isn't an implementation rather, methods are implementations. When we explored operation contracts, in UML terms we were exploring the definition of constraints for UML operations.
UML Methods:
A UML method is the implementation of an operation; if constraints are defined, the method must satisfy them. A method may be illustrated several ways, including:
- in interaction diagrams, by the details and sequence of messages
- in class diagrams, with a UML note symbol stereotyped with «method»
0 comments:
Post a Comment